HydrogenAudio

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

Title: exhale - Open Source USAC encoder
Post by: IgorC on 2020-02-25 22:57:44
EDIT: PLEASE READ THE FIRST 10 POSTS OF THIS THREAD FIRST BEFORE POSTING A QUESTION OR BUG REPORT!

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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC encoder
Post by: m14u on 2020-04-30 19:23:16
del. my bad. wrong resamling.  O:)
Title: Re: exhale - Open Source USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC encoder
Post by: m14u on 2020-05-06 14:55:57
little more
Title: Re: exhale - Open Source USAC 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 USAC 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 USAC 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 USAC 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 USAC encoder
Post by: m14u on 2020-05-08 21:34:43
mk.II
Title: Re: exhale - Open Source USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC encoder
Post by: m14u on 2020-05-11 07:17:18
another little more
Title: Re: exhale - Open Source USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC encoder
Post by: fabiorug on 2020-05-19 20:18:32
excellent quality.
But consider  vbr and cbr options in the future to force a low bitrate.
It is excellent for music, but I like also speech options and not always 64 kbps.
I know to now the focus is music and the encoder is still new.
Also when we will have USAC decoder on VLC, lav filters or Foobar (even of mobile, now is only with a component in PC)?

Still I'd like an encoder that rarely goes more than 63 kbps.
Title: Re: exhale - Open Source USAC 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 USAC 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 USAC 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 USAC encoder
Post by: john33 on 2020-05-20 07:48:23
No problem, thanks for the explanation. Once the encoder is finalised, I'm sure we would be happy to host a Mac compile at Rarewares if you would like us to do so.
Title: Re: exhale - Open Source USAC encoder
Post by: fabiorug on 2020-05-20 10:17:54
For example I can't use VBR 79 kbps or vbr 121 kbps.
Title: Re: exhale - Open Source USAC encoder
Post by: m14u on 2020-05-20 11:09:24
the VBR is not a panacea
Title: Re: exhale - Open Source USAC 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 USAC encoder
Post by: C.R.Helmrich on 2020-05-21 00:20:09
Thanks, Igor! Yes, some more volunteers in the 32-vs-44.1-kHz test would be very nice.

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

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

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

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

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

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

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

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

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

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

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

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

Finally the same tracks created with exhale #2.

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

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

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

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

Christian
Title: Re: exhale - Open Source USAC encoder
Post by: fabiorug on 2020-05-21 08:15:42
a serious question. How stereo works in Usac or in exhale? Is there joint stereo at certain bitrate, or stereo like opus that uses very few kbps like 2 kbps, or normal stereo so 32+32 kbps vbr, 32 kbps if the track is mono or 64 kbps stereo. I haven't test much the program so I don't know very well what are the bitrates for mono.
Celona, how to install usac in afconvert. How much it costs?
Title: Re: exhale - Open Source USAC 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 USAC 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 USAC encoder
Post by: C.R.Helmrich on 2020-05-21 11:24:24
Thanks very much, m14u! For sampling rates between 22.05 and 44.1 kHz, the resulting bit-rates seem to be quite balanced now, so I think I can stop adjusting here. For lower sampling rates, see the following answer.

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

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

Chris
Title: Re: exhale - Open Source USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC encoder
Post by: IgorC on 2020-05-21 19:06:54
a serious question. How stereo works in Usac or in exhale? Is there joint stereo at certain bitrate, or stereo like opus that uses very few kbps like 2 kbps, or normal stereo so 32+32 kbps vbr, 32 kbps if the track is mono or 64 kbps stereo. I haven't test much the program so I don't know very well what are the bitrates for mono.
Celona, how to install usac in afconvert. How much it costs?

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

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

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

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

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

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

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

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

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

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

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

The length of each piece is deliberately one minute.

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

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

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

AMR-NB - 8 kHz mono - 96.038 byte

AMR-WB - 16 kHz mono - 183.009 byte

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

Speex - 8 kHz mono - 118.811 byte

Speex - 16 kHz mono - 214.811 byte

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

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

Opus - 8 kHz mono - 125.111 byte

Opus - 12 kHz mono - 152.936 byte

Opus - 16 kHz mono - 180.917 byte

Opus - 24 kHz mono - 241.385 byte

Opus - 48 kHz mono - 423.360 byte

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

Opus - 48 kHz mono - 363.901 byte
Title: Re: exhale - Open Source USAC 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: exhale - Open Source USAC 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: exhale - Open Source USAC 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: exhale - Open Source USAC 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: exhale - Open Source USAC 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: exhale - Open Source USAC 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: exhale - Open Source USAC 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: exhale - Open Source USAC 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: exhale - Open Source USAC encoder
Post by: fabiorug on 2020-05-26 13:03:14
no, I'm not interested in unknown formats. Thanks the same.
Title: Re: exhale - Open Source USAC 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: exhale - Open Source USAC 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: exhale - Open Source USAC 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: exhale - Open Source USAC encoder
Post by: celona on 2020-05-26 19:45:48
Exhale @a8511608

# 8 12 16 24 32 48 kHz

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

# 8 12 16 24 32 48 kHz

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

# 8 12 16 24 32 48 kHz

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

# 8 12 16 24 32 48 kHz

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

# 8 12 16 24 32 48 kHz

9
Title: Re: exhale - Open Source USAC 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: exhale - Open Source USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC encoder
Post by: m14u on 2020-05-29 16:19:44
exhale support unicode?
Title: Re: exhale - Open Source USAC 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 USAC 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 USAC 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 USAC encoder
Post by: m14u on 2020-05-30 19:04:29
del
Title: Re: exhale - Open Source USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC encoder
Post by: m14u on 2020-06-12 23:24:42
[...] not on Linux yet [...]
you mean wine?
Title: Re: exhale - Open Source USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC encoder
Post by: m14u on 2020-06-13 21:59:59
to AiZ
are unicode is worked?
Title: Re: exhale - Open Source USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC encoder
Post by: john33 on 2020-06-17 21:35:33
Great, thanks ! :)
Title: Re: exhale - Open Source USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC encoder
Post by: fabiorug on 2020-07-27 08:27:46
Thanks.
Title: Re: exhale - Open Source USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC encoder
Post by: ani_Jackal3 on 2020-08-05 22:45:02
Thanks.
Title: Re: exhale - Open Source USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC encoder
Post by: m14u on 2020-08-18 17:02:53
aa44938c
caramba!
Title: Re: exhale - Open Source USAC 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 USAC encoder
Post by: soundping on 2020-08-20 09:07:50
Thanks, NR   ;D
Title: Re: exhale - Open Source USAC 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 USAC encoder
Post by: m14u on 2020-08-20 19:58:11
"Free 21 day trial"
burn in hell
Title: Re: exhale - Open Source USAC 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 USAC 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 USAC 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 USAC 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 USAC encoder
Post by: includemeout on 2020-08-21 16:04:22
Yeah, got it totally t*ts up. Sorry!
Title: Re: exhale - Open Source USAC encoder
Post by: soundping on 2020-08-22 00:55:57
I must have stumbled into the flame room.  :))
Title: Re: exhale - Open Source USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC encoder
Post by: m14u on 2020-08-27 10:27:15
slower than what?
Title: Re: exhale - Open Source USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC encoder
Post by: m14u on 2020-09-06 22:52:01
whats about playing this files on PC ?
Title: Re: exhale - Open Source USAC 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 USAC 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 USAC encoder
Post by: john33 on 2020-09-26 21:33:10
New compiles on the Rarewares-aac encoders page. :)
Title: Re: exhale - Open Source USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC encoder
Post by: fabiorug on 2020-10-20 21:04:40
it isn't integrated.
Title: Re: exhale - Open Source USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC 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 USAC encoder
Post by: m14u on 2020-10-28 22:49:16
in the name of Justice!
8b561924
Title: Re: exhale - Open Source USAC 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 USAC 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 USAC 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
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2020-11-10 19:50:34
I've now managed to implement a first working (= standard compliant) version of xHE-AAC with SBR. Note that it does not yet sound good because exhale so far doesn't write any meaningful SBR data. Still, I'll share the source code in the hope that some of you have time to test it a bit - the more help I get with testing, the faster I can release this officially. The open test points, focusing on encoding via exhale and playback via e.g. foobar2000 with kode54's packet decoder (https://www.foobar2000.org/components/view/foo_pd_aac), are listed below. Please let me know if you encounter any problems.

The support for SBR is currently only published in branch develop (https://gitlab.com/ecodis/exhale/-/tree/develop) of the exhale's GitLab source repository. It provides the new CVBR modes a - g as command-line options for coding with rates as low as ~36 kbit/s stereo (or ~20 kbit/s mono), complementing the existing modes 0 - 6 and activating 2:1 SBR (the core encoder operates at half the input sampling rate). The input sampling rate range supported by exhale when encoding xHE-AAC with SBR is 24 - 96 kHz, inclusive.

Open test points:

Known issues:

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2020-11-10 21:46:36
Untested Intel compiles of exhale-develop-1259070c:

www.rarewares.org/files/aac/exhale-develop-1259070c_x64.zip (http://www.rarewares.org/files/aac/exhale-develop-1259070c_x64.zip)

www.rarewares.org/files/aac/exhale-develop-1259070c_x86.zip (http://www.rarewares.org/files/aac/exhale-develop-1259070c_x86.zip)

:)
Title: Re: exhale - Open Source USAC encoder
Post by: m14u on 2020-11-10 22:05:15
del.
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2020-11-11 01:37:09
Doesn't appear to be fully implemented yet, as I noticed from the source code that doesn't actually generate any SBR data, just fills it out with null info. The resulting files have pretty much nothing but spectral mirroring of the lower frequency data at a lower amplitude. Seems to be valid data, though. Also, Big Sur seems to be able to decode it just fine.

Which you just said, right?
Title: Re: exhale - Open Source USAC encoder
Post by: guruboolez on 2020-11-11 10:04:04
Wow, Christmas is coming earlier this year :)

I couldn't resist and I tried few files before going to bed.
• JohnV x64 compiles seems to be fine on my side: no visible encoding issue with foobar2000's converter.
• gapless playback: tested with one disc: gapless was fine (it was mode a & c on 16/44100 files).
• seeking: I hear some glitches/weird short noise on seeking, but it usually appeared once or twice on the same file then can't be reproduced again with the same file.
• no error at the end of playback

I won't talk about sound quality yet as I didn't made blind comparisons. I got ~36kbps with mode a. And my early feeling at this bitrate is enthousiasm :)
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2020-11-11 12:21:43
Doesn't appear to be fully implemented yet, as I noticed from the source code that doesn't actually generate any SBR data, just fills it out with null info. The resulting files have pretty much nothing but spectral mirroring of the lower frequency data at a lower amplitude. Seems to be valid data, though. Also, Big Sur seems to be able to decode it just fine.

Which you just said, right?
Exactly, that's the behavior I currently expect. I'll try to encode some more reasonable SBR envelope data by the weekend, hopefully that will already make it sound very close to the intended behavior.

I won't talk about sound quality yet as I didn't made blind comparisons. I got ~36kbps with mode a. And my early feeling at this bitrate is enthousiasm :)
With the next changes (maybe already next weekend) feel free to give it a listen at 36 and 48 kbit/s if you're so enthusiastic ;) And thanks for mentioning the average bit-rate you're getting, this is something I forgot to mention in my last post: I'm very much interested in what average bit-rates people get on their music collections even with this early SBR version.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2020-11-12 08:37:21
I hope not to find people here who want to listen to music at 36kbps. In my opinion it is a bitrate that best affects news channels for future FM DRM broadcasts or for spoken podcasts.

In this scenario a low pass filter can attenuate too obvious artifacts or automatically resampling 32khz can get you very close to the bitrates of the features not implemented, but not for musical content. Currently the same result can be obtained with AAC LC by sampling at 16khz, the bitrates used in telephony are reached.
Title: Re: exhale - Open Source USAC encoder
Post by: AiZ on 2020-11-13 23:24:17
Hello,

Quick testing of branch develop 16d3fbac :
- There is life above 11kHz, hurray!  :)
- Numerical options produce (much) higher bitrate than 1.0.8.
- FDK-AAC packet decoder 1.14 seems Ok.

Edit: There's definitively something wrong with non-SBR files generated with this version, I can even ABX them! :D

   AiZ
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2020-11-13 23:50:27
Nicely spotted ;) Yes, I added some more SBR code in branch develop (https://gitlab.com/ecodis/exhale/-/tree/develop). It's still missing adequate time and frequency resolution, so some material won't sound that great in the high-frequency range. But as AiZ noticed, the SBR data written to the files is now more meaningful, and already quite listenable, at least to my ears. But:
- Numerical options produce (much) higher bitrate than 1.0.8.
I cannot reproduce this. For modes 0-9, I actually get almost identical results with 1.0.8 and this version (let's call it 1.1 alpha since it's not yet a release candidate).
Ouch, I had included a quick value test into my last commit. Sorry about that, the new revision 1281acbe (https://gitlab.com/ecodis/exhale/-/commit/1281acbe) should fix this. Let me know if you still get very different results than with 1.0.8 for modes 0-9.

I hope not to find people here who want to listen to music at 36kbps. In my opinion it is a bitrate that best affects news channels for future FM DRM broadcasts or for spoken podcasts.
I agree that CVBR mode "a" shouldn't be used unless it is really necessary to limit the bit-rate so much (as with some Web radio and podcast services, as you mentioned). But with the above 1.1 alpha it actually doesn't sound that terrible, so I recommend you give it a try.

For clarification: when using the SBR modes "a"-"g", do not reduce the input sampling rate. The SBR encoder already does that internally, so you get the best audio quality by just feeding 44.1 or 48 kHz into the exhale application. Regarding the choice of 44.1 or 48 kHz: this is somewhat a matter of taste, so I suggest trying it out. I personally tend towards 48-kHz input with mode "b", for example, but the difference is very subtle.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: desokami on 2020-11-14 06:00:27
Try to test 5.1 files, but foobar don't play it with decoder version 1.14. Can help?
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2020-11-14 08:02:32
Intel compiles of exhale-develop-1.1a-1281acbe:

www.rarewares.org/files/aac/exhale-develop-1.1a-1281acbe_x64.zip (http://www.rarewares.org/files/aac/exhale-develop-1.1a-1281acbe_x64.zip)

www.rarewares.org/files/aac/exhale-develop-1.1a-1281acbe_x86.zip (http://www.rarewares.org/files/aac/exhale-develop-1.1a-1281acbe_x86.zip)
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2020-11-14 21:54:59
Try to test 5.1 files, but foobar don't play it with decoder version 1.14. Can help?
Exhale isn't really meant to encode anything but mono or stereo, and FDK-AAC can't decode anything more than that from USAC streams at this point anyway.
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2020-11-17 21:26:59
I tried to compile Exhale (develop 6fe06fa7) with one of the new Apple Silicon M1 based Macs.

I got a working executable and no compilation errors but for the older 64bit platform; am I too optimistic to believe that adding the ARM64 platform is enough?
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2020-11-17 21:42:06
Intel compiles of exhale-develop-1.1a-6fe06fa7 available here:

www.rarewares.org/files/aac/exhale-develop-1.1a-6fe06fa7_x64.zip (http://www.rarewares.org/files/aac/exhale-develop-1.1a-6fe06fa7_x64.zip)

www.rarewares.org/files/aac/exhale-develop-1.1a-6fe06fa7_x86.zip (http://www.rarewares.org/files/aac/exhale-develop-1.1a-6fe06fa7_x86.zip)

:)
Title: Re: exhale - Open Source USAC encoder
Post by: AiZ on 2020-11-17 21:54:01
Warning, you have to modify src/lib/tempAnalysis.cpp as in commit 1281acbe.
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2020-11-17 21:57:12
Thanks, but my goal was to get a native encoder for the M1 SoC used in new Macs. Now works only temporarily via Rosetta 2.

https://developer.apple.com/documentation/xcode/writing_arm64_code_for_apple_platforms
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2020-11-17 22:11:27
For the record, the new commit can be considered a 1.1.0 beta version (increased SBR temporal resolution).

Warning, you have to modify src/lib/tempAnalysis.cpp as in commit 1281acbe.
That shouldn't be necessary anymore, the latest commit includes that fix.

Thanks very much, celona, for trying out ARM compilation. I have absolutely no experience with ARM or Mac platforms and currently no access to either of those, but in this thread at
https://hydrogenaud.io/index.php?topic=118888.msg984585#msg984585
some earlier, eventually successful attempts were documented.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: AiZ on 2020-11-17 22:20:36
Warning, you have to modify src/lib/tempAnalysis.cpp as in commit 1281acbe.
That shouldn't be necessary anymore, the latest commit includes that fix.

Sorry, you're right, I messed up with downloaded files.  :-[
Must go to bed...
Title: Re: exhale - Open Source USAC encoder
Post by: diizzy on 2020-11-18 23:40:26
For the record, the new commit can be considered a 1.1.0 beta version (increased SBR temporal resolution).

Warning, you have to modify src/lib/tempAnalysis.cpp as in commit 1281acbe.
That shouldn't be necessary anymore, the latest commit includes that fix.

Thanks very much, celona, for trying out ARM compilation. I have absolutely no experience with ARM or Mac platforms and currently no access to either of those, but in this thread at
https://hydrogenaud.io/index.php?topic=118888.msg984585#msg984585
some earlier, eventually successful attempts were documented.

Chris

Latest release compiles fine on aarch64/arm64 on FreeBSD 13-CURRENT

Code: [Select]
root@tsukihi:/usr/ports/audio/exhale # file /usr/local/bin/exhale
/usr/local/bin/exhale: ELF 64-bit LSB executable, ARM aarch64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 13.0 (1300124), FreeBSD-style, stripped
root@tsukihi:/usr/ports/audio/exhale # exhale -h
  ---------------------------------------------------------------------
 | exhale - ecodis extended high-efficiency and low-complexity encoder |
 |                                                                     |
 | version 1.0.8 (x64, built on Nov 19 2020) - written by C.R.Helmrich |
  ---------------------------------------------------------------------
Only issue is that it reports arch incorrectly, x64 isn't aarch64/arm :-)
Title: Re: exhale - Open Source USAC encoder
Post by: IgorC on 2020-11-19 04:34:16
I've quickly skimmed through a few albums.
I don't need to perform any  test to say that now exhale with a new SBR blows away everything I've heard at 48 kbps.  :-\  ::)  :-[
Title: Re: exhale - Open Source USAC encoder
Post by: Kamedo2 on 2020-11-19 12:35:50
I've got these warnings when I used the seek bar of the foobar2000 v1.5.3.

Code: [Select]
File verification warning: Decoding error: Unsupported format or corrupted file, frame: 1095 of 7354
File verification warning: Decoding error: Unsupported format or corrupted file, frame: 1096 of 7354
I used http://www.rarewares.org/files/aac/exhale-develop-1.1a-6fe06fa7_x64.zip to encode.

Updating the fdk-aac packet decoder (https://www.foobar2000.org/components/view/foo_pd_aac/release/1.14) to the latest version, Version: 1.14, doesn't work.
Updating the foobar to v1.6.2 doesn't work.
It seems to happen on any music files encoded at exhale quality 0, 1, 2, 7.
Everything is fine if I don't touch the seek bar.
Title: Re: exhale - Open Source USAC encoder
Post by: LithosZA on 2020-11-19 13:09:07
What's the difference between enhanced SBR and SBR? Is exhale using normal SBR?
Title: Re: exhale - Open Source USAC encoder
Post by: m14u on 2020-11-19 14:02:54
I've got these warnings when I used the seek bar of the foobar2000 v1.5.3.
dev_1.1a_6fe06fa7 modes 0, a; fb2k_1.6.2; decoder_1.14; via wine: don't confirm
Title: Re: exhale - Open Source USAC encoder
Post by: capma on 2020-11-19 15:00:48
In comparison, exhale a sounds much, much better than fhgaacenc --vbr 1 (HE-AACv2). Keep up the good work!
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2020-11-19 20:14:46
Thanks very much, Igor and capma!

Latest release compiles fine on aarch64/arm64 on FreeBSD 13-CURRENT
...
Only issue is that it reports arch incorrectly, x64 isn't aarch64/arm :-)
Thanks for checking and for the info! Can you tell me how I can complete the following code to print out "ARM" (regardless of whether it's 32-bit or 64-bit) instead of "x64" in your case?
Code: [Select]
#if (WHAT GOES HERE?) // ARM platform
    fprintf_s (stdout, "exhale %s.%s%s (ARM",
#elif defined (_WIN64) || defined (WIN64) || defined (_LP64) || defined (__LP64__) || defined (__x86_64) || defined (__x86_64__)
    fprintf_s (stdout, "exhale %s.%s%s (x64",
#else // 32-bit OS
    fprintf_s (stdout, "exhale %s.%s%s (x86",
#endif

I've got these warnings when I used the seek bar of the foobar2000 v1.5.3.
Code: [Select]
File verification warning: Decoding error: Unsupported format or corrupted file, frame: 1095 of 7354
File verification warning: Decoding error: Unsupported format or corrupted file, frame: 1096 of 7354
...
It seems to happen on any music files encoded at exhale quality 0, 1, 2, 7.
Everything is fine if I don't touch the seek bar.
Strange, I haven't seem that myself either since the first alpha. But I'll check again.

What's the difference between enhanced SBR and SBR? Is exhale using normal SBR?
Enhanced SBR has some more low-bit-rate tools inside which exhale doesn't implement (because they are not needed above 32 kbit/s stereo or so). If you're interested in details about these additional tools, see https://www.gel.usherbrooke.ca/gournay/documents/publications/JAES_V61_12_PG956.pdf sections 3.3.2 - 3.3.5.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: diizzy on 2020-11-19 22:36:56
Hi,

As far as I can tell:

__aarch64__ and __arm64__ --> 64-bit
__arm__ for 32-bit

Refs:
https://reviews.llvm.org/D4379
https://wiki.debian.org/ArchitectureSpecificsMemo
https://sourceforge.net/p/predef/wiki/Architectures/
Title: Re: exhale - Open Source USAC encoder
Post by: guruboolez on 2020-11-20 21:12:00
With the next changes (maybe already next weekend) feel free to give it a listen at 36 and 48 kbit/s if you're so enthusiastic ;) And thanks for mentioning the average bit-rate you're getting, this is something I forgot to mention in my last post: I'm very much interested in what average bit-rates people get on their music collections even with this early SBR version.

Chris
I resumed my bitrate table (last tab):
https://docs.google.com/spreadsheets/d/18lGNoBB0ZB2A4SGAw3_z-5L7gzl54MG3D_V7tf2jII8/edit?usp=sharing

The computer will also run overnight. Two modes (a and c) are already completed: 39,1 kbps for music with a mode, and 56,9 kbps with c [6fe06fa7]. Audiobooks and stereo movies are even lower (32…34 kbps for a, and 50 for c).
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2020-11-20 21:40:09
__aarch64__ and __arm64__ --> 64-bit
__arm__ for 32-bit
Thanks a lot! I created a first release candidate of version 1.1.0, can you please check the latest revision of Git branch "develop" (5373500b (https://gitlab.com/ecodis/exhale/-/commit/5373500) and tell me if it works for you?

Two modes (a and c) are already completed: 39,1 kbps for music with a mode, and 56,9 kbps with c [6fe06fa7]. Audiobooks and stereo movies are even lower (32…34 kbps for a, and 50 for c).
Great, thanks. Looks OK to me. The latest revision (see above) includes some more SBR related fine-tunings for stereo and/or 48 kHz.

Btw, I also observed sporadic sound glitches when seeking through SBR enabled xHE-AAC files. Unfortunately, they can be quite loud. I currently have no idea whether this is an issue with the files generated by exhale or an issue with the packet decoder for foobar2000, and what the issue might be. So to give myself and others some more time to identify the issue, I'll tag a "final release candidate" of exhale 1.1.0 on Gitlab at the end of this month and wait with the final release until the end of the year.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2020-11-20 22:05:49
Intel compiles of exhale-develop-1.1rc1-5373500b:

www.rarewares.org/files/aac/exhale-develop-1.1rc1-5373500b_x64.zip (http://www.rarewares.org/files/aac/exhale-develop-1.1rc1-5373500b_x64.zip)

www.rarewares.org/files/aac/exhale-develop-1.1rc1-5373500b_x86.zip (http://www.rarewares.org/files/aac/exhale-develop-1.1rc1-5373500b_x86.zip)

:)
Title: Re: exhale - Open Source USAC encoder
Post by: diizzy on 2020-11-21 08:48:51
__aarch64__ and __arm64__ --> 64-bit
__arm__ for 32-bit
Thanks a lot! I created a first release candidate of version 1.1.0, can you please check the latest revision of Git branch "develop" (5373500b (https://gitlab.com/ecodis/exhale/-/commit/5373500) and tell me if it works for you?
Hi,

Code: [Select]
version 1.1RC (ARM, built on Nov 21 2020) - written by C.R.Helmrich

Any reason why you decided not print 32 vs 64-bit like on x86?
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2020-11-21 14:01:30
Well, I have only 3 characters available (otherwise the header formatting would have to be changed), and I think all ARM versions since v8 from 2013 are 64-bit (are 32-bit versions still widely used?).

Btw, the exhale 1.1.0 RC1 gives identical results to 1.0.8 for all non-SBR modes when the input sampling rate is higher than 32 kHz. In case anyone is wondering whether they should already update.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: alter4 on 2020-11-21 14:06:52
Can confirm decoding issues in Foobar2000 while seeking with integrity verifier enabler for 1.0.8
https://www.foobar2000.org/components/view/foo_verifier
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2020-11-21 14:20:23
For 1.0.8? So it's not an SBR related issue. Kamedo2 also provided some more details and a test encoding which confirms that. Here's the strange part: with my own compilation of exhale.exe (1.1RC) and the WAV file that he provided, I get the same bitstream (except for different timestamps in the MPEG-4 file header), and on both Windows 10 (version 2004) with foobar2000 1.5.6 and Windows 7 (SP1) with foobar2000 1.6.1, the files play perfectly, including seeking.  :o

So what are the differences between our software configurations? Are you guys using a newer version of Windows? Edit: Are you running the latest Windows update (20H2)? If not, do you have the 2020-11 cumulative update (KB4586781) installed? Both of those are not yet installed on my machine.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: m14u on 2020-11-21 14:31:53
or, foo_verifier buggy
Title: Re: exhale - Open Source USAC encoder
Post by: Rollin on 2020-11-21 15:12:03
Can confirm decoding issues in Foobar2000 while seeking with integrity verifier enabler for 1.0.8
or, foo_verifier buggy
Option "Verify integrity of played tracks and report error immediately" and this  error on seeking have nothing to do with foo_verifier.
Title: Re: exhale - Open Source USAC encoder
Post by: Rollin on 2020-11-21 15:15:18
on both Windows 10 (version 2004) with foobar2000 1.5.6 and Windows 7 (SP1) with foobar2000 1.6.1, the files play perfectly, including seeking.
Have you enabled File->Preferences->Playback->Verify integrity of played tracks and report errors immediately?
I use fb2k 1.6.2 on windows 7 and error is presented.
Title: Re: exhale - Open Source USAC encoder
Post by: m14u on 2020-11-21 16:03:47
yes.
with enabled "Verify integrity [...]" option this error confirmed
Title: Re: exhale - Open Source USAC encoder
Post by: Rollin on 2020-11-21 16:07:49
Since foo_pd_aac is involved, we probably need @kode54 to look into this error (https://hydrogenaud.io/index.php?topic=118888.msg990627#msg990627)
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2020-11-21 17:01:10
Oh, thanks for the info about that checkbox. Yes, now I get that error too on some seeks (not all, though), even with the files created with exhale 1.0.7 (and possibly all earlier versions). Yes, since xHE-AAC does not allow random access in every frame like AAC, I'd kindly ask Peter and kode54 to take a look at the decoder component.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2020-11-22 00:44:59
I already know there is no seeking accuracy. In fact, there isn't even any decoding consistency between any two given full decode runs of FDK-AAC. If someone wants to write a USAC decoder that produces consistent results and supports proper seeking, they're welcome to start from scratch, E: as FDK-AAC is literally the only open source USAC decoder in existence right now, all other solutions are proprietary decoder libraries that are often tied to the operating system.
Title: Re: exhale - Open Source USAC encoder
Post by: Jpt on 2020-11-22 07:08:40
Oh, thanks for the info about that checkbox. Yes, now I get that error too on some seeks (not all, though), even with the files created with exhale 1.0.7 (and possibly all earlier versions). Yes, since xHE-AAC does not allow random access in every frame like AAC, I'd kindly ask Peter and kode54 to take a look at the decoder component.

Chris

Check in my home with exhale-develop-1.1a-6fe06fa7_x64 all is right with option "a" (SBR) and vbr format include (great)
Check with foobar and win 7 (no sp1)
Two questions

1 You adds PS (Parametric stéro) function in your project ? (great this)   8)

2 for input formats, possible adds directly Flac format Because wav format is old, flac is used for many's  players, and many people have audio in this format (flac)

Regards,
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2020-11-22 13:03:46
You're right, kode54, and as long as I don't use that "verify integrity" checkbox and don't seek much (during usual casual listening, that is), it's not really much of a problem. I'm happy that I can listen to xHE-AAC files at all in foobar2000.

1 You adds PS (Parametric stéro) function in your project ? (great this)   8)
No, as I wrote several times (starting at https://hydrogenaud.io/index.php?topic=118888.msg980837#msg980837), that's too much work for me.
Quote
2 for input formats, possible adds directly Flac format Because wav format is old, flac is used for many's  players, and many people have audio in this format (flac)
No, but to encode directly from FLAC (or other formats) you can use foobar2000 (https://gitlab.com/ecodis/exhale#third-party-stdin-foobar2000) or e.g. Moisés Cardona's exhale GUI with FFmpeg (https://moisescardona.me/?s=exhale).

Edit: Thanks again, guruboolez, for the link to your bit-rate table!
I resumed my bitrate table (last tab):
https://docs.google.com/spreadsheets/d/18lGNoBB0ZB2A4SGAw3_z-5L7gzl54MG3D_V7tf2jII8/edit?usp=sharing

The computer will also run overnight. Two modes (a and c) are already completed: 39,1 kbps for music with a mode, and 56,9 kbps with c [6fe06fa7]. Audiobooks and stereo movies are even lower (32…34 kbps for a, and 50 for c).
I noticed in your results that, with SBR, exhale tends to undercode "noisy" music (like metal). I just found the reason for this behavior (some code was active only with 48 kHz but not with 44.1 kHz input) and fixed it (https://gitlab.com/ecodis/exhale/-/commit/f1d66fb3). This affects modes b-g when the input sampling rate is 44.1 kHz. So could you please be so kind and rerun your script for modes b and c? O:) Mode a and all modes fed with 48-kHz audio should not be affected.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: diizzy on 2020-11-22 20:19:52
Well, I have only 3 characters available (otherwise the header formatting would have to be changed), and I think all ARM versions since v8 from 2013 are 64-bit (are 32-bit versions still widely used?).

Btw, the exhale 1.1.0 RC1 gives identical results to 1.0.8 for all non-SBR modes when the input sampling rate is higher than 32 kHz. In case anyone is wondering whether they should already update.

Chris

You have a lot of devices still on 32-bit, that includes RPi (not all) and pretty much the complete range of Amazon tablets etc not to mention SoCs that doesn't target cheap as chips market like IMX-series etc or simply LTS.
Title: Re: exhale - Open Source USAC encoder
Post by: Jpt on 2020-11-23 06:45:03
...

Okay, many's thank's for your response quickly
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2020-11-23 12:03:33
Might be 'jumping the gun' here ( :D ) but Intel compiles of exhale-develop-1.1rc2-f1d66fb3 are below.

www.rarewares.org/files/aac/exhale-develop-1.1rc2-f1d66fb3_x64.zip (http://www.rarewares.org/files/aac/exhale-develop-1.1rc2-f1d66fb3_x64.zip)

www.rarewares.org/files/aac/exhale-develop-1.1rc2-f1d66fb3_x86.zip (http://www.rarewares.org/files/aac/exhale-develop-1.1rc2-f1d66fb3_x86.zip)
Title: Re: exhale - Open Source USAC encoder
Post by: guruboolez on 2020-11-24 14:27:36
I noticed in your results that, with SBR, exhale tends to undercode "noisy" music (like metal). I just found the reason for this behavior (some code was active only with 48 kHz but not with 44.1 kHz input) and fixed it (https://gitlab.com/ecodis/exhale/-/commit/f1d66fb3). This affects modes b-g when the input sampling rate is 44.1 kHz. So could you please be so kind and rerun your script for modes b and c? O:) Mode a and all modes fed with 48-kHz audio should not be affected.

Chris
Some RC2 modes are now completed. I only did some albums with a mode, and resulting bitrate is indeed always identical between beta 6fe06fa7 and RC2. Therefore I have four RC2 results in my table: a-b-c-d.
Average bitrate for music are:
mode amode bmode cmode d
39.1 kbps50.1 kbps59,0 kbps76,6 kbps
——+ 11,0 kbps+ 8,9 kbps+17,6 kbps
I don't know if it's easily feasible or not but I think that current presets should be better balanced. There's a big gap between mode c and mode d (60 → 76 kbps).  But the gap is twice shorter between mode b and mode c (50 → 59 kbps). Assuming that RC1 and RC2 are similar, the gap between de ≈ 9 kbps and ef ≈ 15 kbps.

Or is it intended?

EDIT: thanks John33 for the binaries :)
Title: Re: exhale - Open Source USAC encoder
Post by: IgorC on 2020-11-24 19:01:15
I have very close numbers to what Guru mentions.
I see that  SBR bitrates are 36+n*12 kbps and   I think humanity gets used to 48/64/80 kbps  :)
It's also worth to mention that HE-AAC's  SBR was useful up to ~72 kbps ... so maybe 48/64/72.

Anyway current formula 36+n*12 works  fine too.


Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2020-11-25 00:20:26
Thanks, guruboolez and Igor! You're right, that was close, but not quite what I intended. Indeed, what I wanted was a constant difference of around 11 kbit/s between the SBR modes (for stereo, a bit more at high rates, a bit less at low rates), so something like:

mode amode bmode cmode d
39 kbps49 kbps60 kbps72 kbps
——+10 kbps+11 kbps+12 kbps
and so on for the higher modes. I just finished a (hopefully) final RC (7f47aaab (https://gitlab.com/ecodis/exhale/-/commit/7f47aaab)) which fixes a rare bit-rate allocation bug for very loud noise-like audio (infamous GloriousTimes sample here on HA, for example) and packs the SBR data a bit more efficiently. With that version, CVBR modes a and b should now be very close to the above target rates, and I retuned the bit-rates for modes c and d to match the target rates (60 and 72 kbit/s, respectively) more closely.

By the way, since the previously discussed seeking issues were found not to be caused by exhale and I have only one more minor issue on my to-do list, I might actually be able to make a final 1.1.0 release of exhale on the weekend :)

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2020-11-25 02:14:07
Maybe I'm already dreaming, before tonight I have compiled Exhale without errors for Apple Silicon.

I attach the obtained ARM64 file (https://hydrogenaud.io/index.php?action=dlattach;sa=tmpattach;attach=18311;topic=118888) which works perfectly.

Tonight I have compiled the Exhale commit 7f47aaab (https://gitlab.com/ecodis/exhale/-/commit/7f47aaab) for macOS x86_64 (https://hydrogenaud.io/index.php?action=dlattach;sa=tmpattach;attach=18310;topic=118888) with no problems.

Now compiling for ARM64 (Apple Silicon M1) from Exhale commit 7f47aaab (https://gitlab.com/ecodis/exhale/-/commit/7f47aaab) I get the following errors.

% make release

/Library/Developer/CommandLineTools/usr/bin/make -C src/lib  release MM32=0
/Library/Developer/CommandLineTools/usr/bin/make -C src/app  release MM32=0
g++ -o ../../bin/exhale -Wall   ../../build/basicMP4Writer.r.o ../../build/basicWavReader.r.o ../../build/exhaleApp.r.o ../../build/exhaleAppPch.r.o ../../build/loudnessEstim.r.o -L../../lib -ldl -lpthread -lexhale
ld: warning: ignoring file ../../build/basicMP4Writer.r.o, building for macOS-arm64 but attempting to link with file built for unknown-x86_64
ld: warning: ignoring file ../../build/basicWavReader.r.o, building for macOS-arm64 but attempting to link with file built for unknown-x86_64
ld: warning: ignoring file ../../build/exhaleApp.r.o, building for macOS-arm64 but attempting to link with file built for unknown-x86_64
ld: warning: ignoring file ../../build/loudnessEstim.r.o, building for macOS-arm64 but attempting to link with file built for unknown-x86_64
ld: warning: ignoring file ../../lib/libexhale.a, building for macOS-arm64 but attempting to link with file built for macOS-x86_64
ld: warning: ignoring file ../../build/exhaleAppPch.r.o, building for macOS-arm64 but attempting to link with file built for unknown-x86_64
Undefined symbols for architecture arm64:
  "_main", referenced from:
     implicit entry/start for main executable
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [../../bin/exhale] Error 1
make: *** [release] Error 2

I'm going to sleep and tomorrow I'll try to figure out what I did wrong. I just remember compiling after the command:
export ARCHFLAGS='arch arm64'
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2020-11-25 03:21:33
I'm an idiot. I closed Terminal and did it all over again, now it works in every 64bit Mac.

exhale_ 7f47aaab_arm64.zip (https://hydrogenaud.io/index.php?action=dlattach;sa=tmpattach;attach=post_tmp_134208_e4c3291e35008b715a7f513ae32da7fc;topic=118888) (109.01 KB)

exhale_ 7f47aaab_x86_64.zip (https://hydrogenaud.io/index.php?action=dlattach;sa=tmpattach;attach=post_tmp_134208_4f5f8433ae0d7229ee00195873568262;topic=118888) (119.04 KB)

exhale_ 7f47aaab_fat_arm64_x86_64.zip (https://hydrogenaud.io/index.php?action=dlattach;sa=tmpattach;attach=post_tmp_134208_5cfa7c76d3266b86642326f247500f7e;topic=118888) (228.03 KB) [This fat binary contains both versions and run in every 64bit Mac]

  ---------------------------------------------------------------------
 | exhale - ecodis extended high-efficiency and low-complexity encoder |
 |                                                                     |
 | version 1.1RC (ARM, built on Nov 25 2020) - written by C.R.Helmrich |
  ---------------------------------------------------------------------

 Copyright 2018-2020 C.R.Helmrich, project ecodis. See License.htm for details.

 This software is made available under the exhale Copyright License and comes
 with ABSOLUTELY NO WARRANTY. This software may be subject to other third-party
 rights, including patent rights. No such rights are granted under this License.

 Usage:   exhale preset [inputWaveFile.wav] outputMP4File.m4a

 where

 preset   =  # (0-9)  low-complexity standard compliant xHE-AAC at 16*#+48 kbit/s
         (a-g)  low-complexity compliant xHE-AAC with SBR at 12*#+36 kbit/s

 inputWaveFile.wav  lossless WAVE audio input, read from stdin if not specified

 outputMP4File.m4a  encoded MPEG-4 bit-stream, extension should be .m4a or .mp4


 Notes:   The above bit-rates are for stereo and change for mono or multichannel.
    Use filename prefix ./ for the current directory if this executable was
   called with a path (call: /Users/christian/Downloads/exhale).
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2020-11-25 08:37:50
And here are Intel compiles of exhale-develop-1.1rc3-7f47aaab:

www.rarewares.org/files/aac/exhale-develop-1.1rc3-7f47aaab_x64.zip (http://www.rarewares.org/files/aac/exhale-develop-1.1rc3-7f47aaab_x64.zip)

www.rarewares.org/files/aac/exhale-develop-1.1rc3-7f47aaab_x86.zip (http://www.rarewares.org/files/aac/exhale-develop-1.1rc3-7f47aaab_x86.zip)

:)
Title: Re: exhale - Open Source USAC encoder
Post by: guruboolez on 2020-11-25 10:08:05
With that version, CVBR modes a and b should now be very close to the above target rates, and I retuned the bit-rates for modes c and d to match the target rates (60 and 72 kbit/s, respectively) more closely.

And here are Intel compiles of exhale-develop-1.1rc3-7f47aaab:
:)

Mode a to d with RC3 are baking  ;)
Title: Re: exhale - Open Source USAC encoder
Post by: guruboolez on 2020-11-25 12:14:26
I just discovered something…
I tried one hour ago a storage service named pCloud (it's a Dropbox/Onedrive-like service). Interesting features (you can buy a lifetime plan,  expensive but discounted for Black Friday). The Android App also includes a basic audio player for streaming purpose. The service claims FLAC and MP3 support, but no mention for something else, which is a bit strange. So after I created my free demo account (few Gb free) I upload an LC-AAC file: playback is fine but tags are apparently not supported (it's my first steps in the service—I could be wrong here).

Just for fun, I uploaded an USAC file (freshly created from RC3, with mode a which means SBR) which has the same container/file extension (m4a). Upload is fine of course, and I tried to guess what kind of error message I'll get on playback. I'm nearly shocked but it works! I checked many times to be sure I didn't make a mistake, but no, eXhale's encodings are playing fine! Seeking is also working (I didn't hear any glitch). No gapless, no album art, no tags, it's very basic. I also sent a full album (<15 Mb  O:) ) and it's fine!

The app probably uses system decoders (Android 9 on my side: USAC is natively supported).

After this discovery I tried with Dropbox, Google Drive and Onedrive: none have audio streaming so it doesn't work.
So if you want to expand the storage capacity of your phone/tablet and try exhale, you can take a look at this service :)


EDIT : it also works with Opus with *.ogg extension.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2020-11-26 01:20:14
Interesting, haven't heard of that service! And thanks for another round of baking ;) I noticed the a and b results are almost complete and look good.

To all developers: I found a rare issue with exhale when running CVBR mode a on 32-kHz input, see https://gitlab.com/ecodis/exhale/-/issues/16
I don't think this is a showstopper for the upcoming release (since it only seems to happen with sampling rates lower than what people should be using), but it might indicate a deeper issue, so it would be great if people familiar with code checkers (e.g., Valgrind) could assist me in figuring out what goes wrong during the last quarter of that WAV sample when encoding it with mode a.

To everyone: if you ever come across an xHE-AAC file generated by exhale which causes error messages during playback or conversion in e.g. foobar2000 (with kode54's FDK-AAC packet decoder), please save that file and let me know! Either here or by filing an issue on Gitlab.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2020-11-26 01:53:21
I have found also errors without SBR, with option 5. The original audio comes from YouTube: https://youtu.be/E338aF6QHu8 (https://youtu.be/E338aF6QHu8).

Listen the attachment at 12 seconds from the start:
Erik Lund - Summertime (https://hydrogenaud.io/index.php?action=dlattach;sa=tmpattach;attach=post_tmp_134208_4d95d6a0bc74a5071d8c50b7f3aff425;topic=118888) (Vlog no copyright music).
Title: Re: exhale - Open Source USAC encoder
Post by: guruboolez on 2020-11-26 18:44:30
Therefore I have four RC2 results in my table: a-b-c-d.
Average bitrate for music are:
mode amode bmode cmode d
39.1 kbps50.1 kbps59,0 kbps76,6 kbps
——+ 11,0 kbps+ 8,9 kbps+17,6 kbps

Update RC3:

mode amode bmode cmode d
38,4 kbps49,5 kbps60,5 kbps73,1 kbps
——+ 11,1 kbps+ 11,0 kbps+12,6 kbps
Balance between SBR presets is now much better with RC3! Congratulation  :)
Title: Re: exhale - Open Source USAC encoder
Post by: IgorC on 2020-11-27 15:54:06
Good to see RC3 hitting target bitrates

I've noted that SBR produces better quality at least for some samples when a source is 48 kHz (generally because higher sampling rate allows slightly higher no-SBR frequency range before SBR starts its range) . Anyway it's very fast observation and I hadn't time to test it in depth.


Title: Re: exhale - Open Source USAC encoder
Post by: guruboolez on 2020-11-28 11:14:08
The RC3 SBR table is now completed (1700 hours of encoded music for 7 presets!):

mode amode bmode cmode dmode emode fmode g
AVERAGE38,4 kbps49,5 kbps60,5 kbps73,1 kbps85,497,4112,3
————+11,1 kbps+11,0 kbps+12,6 kbps+12,3 kbps+12,0 kbps+14,9 kbps
BILLBOARD39,6 kbps51,4 kbps62,9 kbps75,4 kbps87,198,2112,6
BEST-SELLING39,1 kbps50,3 kbps61,2 kbps72,4 kbps84,596,3111,7
CLASSICAL36,5 kbps45,8 kbps56,1 kbps69,8 kbps82,597,1111,8
JAZZ38,1 kbps49,2 kbps61,0 kbps75,7 kbps88,699,0114,2
METAL37,1 kbps48,2 kbps58,7 kbps68,5 kbps81,093,6109,2
ELECTRONIC40,2 kbps51,8 kbps63,4 kbps76,5 kbps88,7100,1114,7
(https://zupimages.net/up/20/48/yt7y.png) (https://zupimages.net/viewer.php?id=20/48/yt7y.png)
Title: Re: exhale - Open Source USAC encoder
Post by: jaybeee on 2020-11-28 12:45:18
awesome work on the huge encoding task and results to help dev, guruboolez  :)
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2020-11-28 21:10:32
Indeed, thanks a lot to (in alphabetical order) celona, diizzy, guruboolez, IgorC, Jukka, m14u, Rollin and all the others for their assistance on this major release change! I just fixed two final issues, one very rare one (the encoder failed to write extremely unlikely bit-chunks of lengths greater than 32 bits properly) and slightly retuned the bit allocation for CVBR mode a with 44.1 kHz input sampling rate one last time (one particular feature was still disabled even though it is enabled with 48 kHz input). Both is fixed in the latest commit (https://gitlab.com/ecodis/exhale/-/commit/c71ec480), which means that

we have an official exhale 1.1.0 release now! :) Consider this a birthday present (https://hydrogenaud.io/index.php?topic=120240) to the community. ;) 🥂

At least on the develop branch. Please let me know if there are compilation issues, especially under ARM, Linux, and MacOS. If not, I'll merge this to the master branch tomorrow and tag it.

Changes since exhale 1.0.8 from last month:
- addition of basic SBR functionality for lower-rate coding down to 18 kbps/channel
- exhaleApp: add support for CVBR modes a—g for encoding with SBR functionality
- exhaleApp: show «ARM» in header and '-v' command on corresponding platforms
- exhaleLib: basic 2:1 SBR encoding with ccfl = 2048, minor fixes and code cleanups

Regarding audio quality improvements, I decided to address only one more thing in the near future, which is to
- calculate / code SBR envelope values at higher frequency resolution (version 1.1.x)

When I started this project, I never thought that 1. exhale would, one day, sound so good even at bit-rates as low as ~39 kbit/s (which, due to the last-minute change mentioned above, is the average bit-rate for stereo with exhale 1.1.0 SBR mode a) and 2. that I would write post number 500 announcing this release. Thanks for all the interest and discussion about this encoder and my work! I'll keep maintaining the source code in case further issues appear, of course.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2020-11-28 21:39:07
And, for checking purposes, here are Intel compiles of exhale-develop-1.1.0rc4-c71ec480 (to become 1.1.0 release tomorrow, all being well!):

www.rarewares.org/files/aac/exhale-develop-1.1.0rc4-c71ec480_x64.zip (http://www.rarewares.org/files/aac/exhale-develop-1.1.0rc4-c71ec480_x64.zip)

www.rarewares.org/files/aac/exhale-develop-1.1.0rc4-c71ec480_x86.zip (http://www.rarewares.org/files/aac/exhale-develop-1.1.0rc4-c71ec480_x86.zip)

:)
Title: Re: exhale - Open Source USAC encoder
Post by: guruboolez on 2020-11-28 21:48:01
Very nice Chris! Exhale really blowed some fresh air on HA.org this year and it reminds me the origin of HA.org (active development of LAME, Musepack, Vorbis, PsyTel AAC…).
Many thanks for all your efforts and for giving us a new perspective on coding efficiency!


And a big THANK YOU for all binaries (John33, Netranger, Celona…)!
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2020-11-29 03:17:58
Here, have some signed and notarized binaries for macOS, Universal 2. I do not know if they will run on <11.1, as I forgot to add the minimum version setting, heh.
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2020-11-29 05:35:11
I also compiled the same version for macOS, sorry if I always forget to notarize, but my executable is slightly larger.

I spent the night banging my head over a formal problem: Exhale comes with instructions to compile from the command line, which is a plus because integral Xcode is too large.

I must imagine that for the average user it is already difficult to compile the code, and to obtain a Universal 2 binary he will have only one machine with which to cross-compile the binary for a platform other than the one in use, to merge them together in a fat binary with the lipo command.

Exhale's instructions is correct only for the platform in use, but perhaps it is better not to complicate the existence too much for new users.

I attach the files necessary to reproduce the error I wrote above.
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2020-11-29 07:52:21
It's quite simple to cross compile from either side. Just add CPPFLAGS and LDFLAGS of:

Code: [Select]
-arch x86_64 -arch arm64

Bam, everything's Universal 2.

Then to sign:

Code: [Select]
codesign --sign "Developer ID Application" --options runtime <executable path>

And notarize:

Code: [Select]
zip -9 exhale-whatever-name-you-want.zip exhale exhaled
xcrun altool --notarize-app --primary-bundle-id "de.ecodis.exhale" --username <your icloud developer account> --password "@keychain:somekeychainitem" --asc-provider <your dev account provider id> --file <the name of the zip file you created above>

There's an extra step for stapling the notarization ticket to the binary, but that's not supported for command line binaries anyway, so you can't do that.
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2020-11-29 11:14:06
We need to simplify :)

I have attached 3 executables for arm64 and 2 universal ones, so I found a way around the cross-compling problems.

If the user has a new Apple Silicon M1, just need to open the Terminal info and select Open with Rosetta, then launch Terminal and type
Code: [Select]
make release
and get the x86_64 binary without errors.

I tried to compile with --environment-overrides but using Rosetta and I get the same error message with
Code: [Select]
make release -e arm64
or with
Code: [Select]
make release -e x86_64
/Library/Developer/CommandLineTools/usr/bin/make -C src/lib  release MM32=0
/Library/Developer/CommandLineTools/usr/bin/make -C src/app  release MM32=0
make: *** No rule to make target `x86_64'.  Stop.


Otherwise if I compile without using Rosetta I get this error message for x86_64:
make: getcwd: Operation not permitted
make: *** No rule to make target `release'.  Stop.


Without Rosetta and without --environment-overrides there is no problem but if I use -e arm64 I get the following errors:
/Library/Developer/CommandLineTools/usr/bin/make -C src/lib  release MM32=0
g++ -c -MMD -MF ../../build/bitAllocation.r.d -MT ../../build/bitAllocation.r.o -fPIC -DMSYS_LINUX -DMSYS_UNIX_LARGEFILE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -I/Users/christian/Downloads/exhale-develop/src/lib/../../include -Wall -Werror -Wshadow -D_FILE_OFFSET_BITS=64 -std=c++11  -O3 -Wuninitialized -o ../../build/bitAllocation.r.o /Users/christian/Downloads/exhale-develop/src/lib/../../src/lib/bitAllocation.cpp
g++ -c -MMD -MF ../../build/bitStreamWriter.r.d -MT ../../build/bitStreamWriter.r.o -fPIC -DMSYS_LINUX -DMSYS_UNIX_LARGEFILE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -I/Users/christian/Downloads/exhale-develop/src/lib/../../include -Wall -Werror -Wshadow -D_FILE_OFFSET_BITS=64 -std=c++11  -O3 -Wuninitialized -o ../../build/bitStreamWriter.r.o /Users/christian/Downloads/exhale-develop/src/lib/../../src/lib/bitStreamWriter.cpp
g++ -c -MMD -MF ../../build/entropyCoding.r.d -MT ../../build/entropyCoding.r.o -fPIC -DMSYS_LINUX -DMSYS_UNIX_LARGEFILE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -I/Users/christian/Downloads/exhale-develop/src/lib/../../include -Wall -Werror -Wshadow -D_FILE_OFFSET_BITS=64 -std=c++11  -O3 -Wuninitialized -o ../../build/entropyCoding.r.o /Users/christian/Downloads/exhale-develop/src/lib/../../src/lib/entropyCoding.cpp
g++ -c -MMD -MF ../../build/exhaleEnc.r.d -MT ../../build/exhaleEnc.r.o -fPIC -DMSYS_LINUX -DMSYS_UNIX_LARGEFILE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -I/Users/christian/Downloads/exhale-develop/src/lib/../../include -Wall -Werror -Wshadow -D_FILE_OFFSET_BITS=64 -std=c++11  -O3 -Wuninitialized -o ../../build/exhaleEnc.r.o /Users/christian/Downloads/exhale-develop/src/lib/../../src/lib/exhaleEnc.cpp
g++ -c -MMD -MF ../../build/exhaleLibPch.r.d -MT ../../build/exhaleLibPch.r.o -fPIC -DMSYS_LINUX -DMSYS_UNIX_LARGEFILE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -I/Users/christian/Downloads/exhale-develop/src/lib/../../include -Wall -Werror -Wshadow -D_FILE_OFFSET_BITS=64 -std=c++11  -O3 -Wuninitialized -o ../../build/exhaleLibPch.r.o /Users/christian/Downloads/exhale-develop/src/lib/../../src/lib/exhaleLibPch.cpp
g++ -c -MMD -MF ../../build/lappedTransform.r.d -MT ../../build/lappedTransform.r.o -fPIC -DMSYS_LINUX -DMSYS_UNIX_LARGEFILE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -I/Users/christian/Downloads/exhale-develop/src/lib/../../include -Wall -Werror -Wshadow -D_FILE_OFFSET_BITS=64 -std=c++11  -O3 -Wuninitialized -o ../../build/lappedTransform.r.o /Users/christian/Downloads/exhale-develop/src/lib/../../src/lib/lappedTransform.cpp
g++ -c -MMD -MF ../../build/linearPrediction.r.d -MT ../../build/linearPrediction.r.o -fPIC -DMSYS_LINUX -DMSYS_UNIX_LARGEFILE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -I/Users/christian/Downloads/exhale-develop/src/lib/../../include -Wall -Werror -Wshadow -D_FILE_OFFSET_BITS=64 -std=c++11  -O3 -Wuninitialized -o ../../build/linearPrediction.r.o /Users/christian/Downloads/exhale-develop/src/lib/../../src/lib/linearPrediction.cpp
g++ -c -MMD -MF ../../build/quantization.r.d -MT ../../build/quantization.r.o -fPIC -DMSYS_LINUX -DMSYS_UNIX_LARGEFILE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -I/Users/christian/Downloads/exhale-develop/src/lib/../../include -Wall -Werror -Wshadow -D_FILE_OFFSET_BITS=64 -std=c++11  -O3 -Wuninitialized -o ../../build/quantization.r.o /Users/christian/Downloads/exhale-develop/src/lib/../../src/lib/quantization.cpp
g++ -c -MMD -MF ../../build/specAnalysis.r.d -MT ../../build/specAnalysis.r.o -fPIC -DMSYS_LINUX -DMSYS_UNIX_LARGEFILE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -I/Users/christian/Downloads/exhale-develop/src/lib/../../include -Wall -Werror -Wshadow -D_FILE_OFFSET_BITS=64 -std=c++11  -O3 -Wuninitialized -o ../../build/specAnalysis.r.o /Users/christian/Downloads/exhale-develop/src/lib/../../src/lib/specAnalysis.cpp
g++ -c -MMD -MF ../../build/specGapFilling.r.d -MT ../../build/specGapFilling.r.o -fPIC -DMSYS_LINUX -DMSYS_UNIX_LARGEFILE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -I/Users/christian/Downloads/exhale-develop/src/lib/../../include -Wall -Werror -Wshadow -D_FILE_OFFSET_BITS=64 -std=c++11  -O3 -Wuninitialized -o ../../build/specGapFilling.r.o /Users/christian/Downloads/exhale-develop/src/lib/../../src/lib/specGapFilling.cpp
g++ -c -MMD -MF ../../build/stereoProcessing.r.d -MT ../../build/stereoProcessing.r.o -fPIC -DMSYS_LINUX -DMSYS_UNIX_LARGEFILE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -I/Users/christian/Downloads/exhale-develop/src/lib/../../include -Wall -Werror -Wshadow -D_FILE_OFFSET_BITS=64 -std=c++11  -O3 -Wuninitialized -o ../../build/stereoProcessing.r.o /Users/christian/Downloads/exhale-develop/src/lib/../../src/lib/stereoProcessing.cpp
g++ -c -MMD -MF ../../build/tempAnalysis.r.d -MT ../../build/tempAnalysis.r.o -fPIC -DMSYS_LINUX -DMSYS_UNIX_LARGEFILE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -I/Users/christian/Downloads/exhale-develop/src/lib/../../include -Wall -Werror -Wshadow -D_FILE_OFFSET_BITS=64 -std=c++11  -O3 -Wuninitialized -o ../../build/tempAnalysis.r.o /Users/christian/Downloads/exhale-develop/src/lib/../../src/lib/tempAnalysis.cpp
ar -crs ../../lib/libexhale.a ../../build/bitAllocation.r.o ../../build/bitStreamWriter.r.o ../../build/entropyCoding.r.o ../../build/exhaleEnc.r.o ../../build/exhaleLibPch.r.o ../../build/lappedTransform.r.o ../../build/linearPrediction.r.o ../../build/quantization.r.o ../../build/specAnalysis.r.o ../../build/specGapFilling.r.o ../../build/stereoProcessing.r.o ../../build/tempAnalysis.r.o
/Library/Developer/CommandLineTools/usr/bin/make -C src/app  release MM32=0
g++ -c -MMD -MF ../../build/basicMP4Writer.r.d -MT ../../build/basicMP4Writer.r.o -fPIC -DMSYS_LINUX -DMSYS_UNIX_LARGEFILE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -I/Users/christian/Downloads/exhale-develop/src/app/../../include -Wall -Werror -Wshadow -D_FILE_OFFSET_BITS=64 -std=c++11  -O3 -Wuninitialized -o ../../build/basicMP4Writer.r.o /Users/christian/Downloads/exhale-develop/src/app/../../src/app/basicMP4Writer.cpp
g++ -c -MMD -MF ../../build/basicWavReader.r.d -MT ../../build/basicWavReader.r.o -fPIC -DMSYS_LINUX -DMSYS_UNIX_LARGEFILE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -I/Users/christian/Downloads/exhale-develop/src/app/../../include -Wall -Werror -Wshadow -D_FILE_OFFSET_BITS=64 -std=c++11  -O3 -Wuninitialized -o ../../build/basicWavReader.r.o /Users/christian/Downloads/exhale-develop/src/app/../../src/app/basicWavReader.cpp
g++ -c -MMD -MF ../../build/exhaleApp.r.d -MT ../../build/exhaleApp.r.o -fPIC -DMSYS_LINUX -DMSYS_UNIX_LARGEFILE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -I/Users/christian/Downloads/exhale-develop/src/app/../../include -Wall -Werror -Wshadow -D_FILE_OFFSET_BITS=64 -std=c++11  -O3 -Wuninitialized -o ../../build/exhaleApp.r.o /Users/christian/Downloads/exhale-develop/src/app/../../src/app/exhaleApp.cpp
g++ -c -MMD -MF ../../build/exhaleAppPch.r.d -MT ../../build/exhaleAppPch.r.o -fPIC -DMSYS_LINUX -DMSYS_UNIX_LARGEFILE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -I/Users/christian/Downloads/exhale-develop/src/app/../../include -Wall -Werror -Wshadow -D_FILE_OFFSET_BITS=64 -std=c++11  -O3 -Wuninitialized -o ../../build/exhaleAppPch.r.o /Users/christian/Downloads/exhale-develop/src/app/../../src/app/exhaleAppPch.cpp
g++ -c -MMD -MF ../../build/loudnessEstim.r.d -MT ../../build/loudnessEstim.r.o -fPIC -DMSYS_LINUX -DMSYS_UNIX_LARGEFILE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -I/Users/christian/Downloads/exhale-develop/src/app/../../include -Wall -Werror -Wshadow -D_FILE_OFFSET_BITS=64 -std=c++11  -O3 -Wuninitialized -o ../../build/loudnessEstim.r.o /Users/christian/Downloads/exhale-develop/src/app/../../src/app/loudnessEstim.cpp
g++ -o ../../bin/exhale -Wall   ../../build/basicMP4Writer.r.o ../../build/basicWavReader.r.o ../../build/exhaleApp.r.o ../../build/exhaleAppPch.r.o ../../build/loudnessEstim.r.o -L../../lib -ldl -lpthread -lexhale
make: *** No rule to make target `arm64'.  Stop.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2020-11-29 12:33:20
Exhale's instructions is correct only for the platform in use, but perhaps it is better not to complicate the existence too much for new users.
I could add a reference to kode54's instructions above to exhale's Wiki,
Quote
I attach the files necessary to reproduce the error I wrote above.
I'm using foobar2000 on Windows 10 with kode54's decoder, and I cannot see any problem with this file. It decodes without errors and even the differences between the decoded and original waveforms are as expected (given the chosen CVBR mode, I assume it's 5). Update: With my own Windows executable I get exactly the same MPEG-4 file as you, by the way (except for, as usual, the timestamps in the MPEG-4 file header).

Can you clarify under which platform and with which player/converter you decode and what issue you observe exactly?

Another update: I just merged version 1.1.0 to exhale's master (https://gitlab.com/ecodis/exhale) branch. The release tag will follow tonight. There's also a legacy (https://gitlab.com/ecodis/exhale/-/tree/legacy) branch now with post-1.0.8 maintenance fixes, in case you want/need to stick with the non-SBR release path 1.0.x. Eventually, there will be a final 1.0.9 tag on that branch.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2020-11-29 14:03:52
Can you clarify under which platform and with which player/converter you decode and what issue you observe exactly?

System:   macOS 11.0.1 (20B29)
Kernel:   Darwin 20.1.0
Name:   Mac mini (M1, 2020)
Model:   Macmini9,1
Chip:   Apple M1

It occurs with the system software, Preview, afplay -q 0 and afplay -q 1 from terminal, and QuickTime player with which I exported the audio file to AAC-LC.

File:           Erik Lund - Summertime15s.m4a
File type ID:   mp4f
Num Tracks:     1
----
Data format:     2 ch,  48000 Hz, 'usac' (0x00000000) 0 bits/channel, 0 bytes/packet, 1024 frames/packet, 0 bytes/frame
                no channel layout.
estimated duration: 15.000000 sec
audio bytes: 213756
audio packets: 706
restricts random access
count of IPFs: 16
initial IPF: 0
cadence of IPFs: one every 45 packets
count of IFs: 0
maximum roll distance: 44 packets
bit rate: 113538 bits per second
packet size upper bound: 607
maximum packet size: 607
audio data file offset: 3718
optimized
audio 720000 valid frames + 1600 priming + 1344 remainder = 722944
----
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2020-11-29 16:37:05
Are you able to export to AIFF or ALAC instead of AAC-LC and can you share the resulting file (in case it is written, even partially)?

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2020-11-29 16:49:51
exhale v1.1.0-c71ec480 (Stable)
Built on November 29, 2020, GCC 10.2.0

Title: Re: exhale - Open Source USAC encoder
Post by: scharfis_brain on 2020-11-29 17:08:25
@C.R.Helmrich:
Thanks for your work! The encoder works great and with ease.
Even mode A - though a bit dull - never sounds annoying.
Too bad DAB+ won't benefit from xHE-AAC.

One question though:
Do you take special care to make every entry in the release notes of exhale having nearly the same width?
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2020-11-29 17:54:45
Intel compiles of exhale-v.1.1.0-c71ec480 now available at Rarewares. :)
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2020-11-29 18:16:07
Too bad DAB+ won't benefit from xHE-AAC.

https://www.drm.org/digital-radio-european-electronic-communications-code-sends-powerful-message-to-countries-adopting-drm-globally/
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2020-11-29 18:30:46
Are you able to export to AIFF or ALAC instead of AAC-LC and can you share the resulting file (in case it is written, even partially)?

Chris

This contains ALAC (https://hydrogenaud.io/index.php?action=dlattach;sa=tmpattach;attach=18359;topic=118888) and this is AIFF (https://hydrogenaud.io/index.php?action=dlattach;sa=tmpattach;attach=post_tmp_134208_50d51febc6d7c0e38c8571fd23ea96e3;topic=118888).
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2020-11-29 19:21:20
Thanks, celona! Now I understand what you mean. What I can confidently say is that the FDK-AAC decodings sound correct (i.e., as expected), and I'm pretty sure exhale is also operating correctly (i.e., according to the USAC standard). I'll check what can be done about this.

One question though:
Do you take special care to make every entry in the release notes of exhale having nearly the same width?
Yes  O:) It's a habit of mine.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: scharfis_brain on 2020-11-29 19:22:48
@celona:
I am well aware that DRM+ specifies xHE-AAC as mandatory.
But DAB+ doesn't.

Also DRM+ is not well adopted. I just receive a handful of DRM shortwave transmissions in the late evenings. None of them uses xHE-AAC.
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2020-11-29 19:55:37
Also DRM+ is not well adopted. I just receive a handful of DRM shortwave transmissions in the late evenings. None of them uses xHE-AAC.

You have to be patient, start on December 21.
https://swling.com/blog/2019/11/eu-vehicle-digital-radio-legislation/
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2020-11-30 06:48:09
Here, have some Universal 2 binaries, yet again. This time, I stripped the release binary. Not sure if the debug one is even debuggable in its signed and hardened runtime state. These should technically also work on as old as 10.9, but I can't test on that. The oldest I can test on is 10.13, and that VM lives in my Linux install, so I'd have to reboot to that just to run that test.
Title: Re: exhale - Open Source USAC encoder
Post by: diizzy on 2020-11-30 11:51:00
Congrats Chris and thanks for the work you've put into and all contributors.
I guess it's worth mentioning that exhale is available in a few repos.
https://repology.org/project/exhale/versions (FreeBSD just got 1.1.0 committed) :-)
Title: Re: exhale - Open Source USAC encoder
Post by: IgorC on 2020-11-30 21:53:47
Congratulations for 1.1.0 release and Thank You to Chris and all people who have helped.   :)

Title: Re: exhale - Open Source USAC encoder
Post by: hyaudio on 2020-12-04 13:24:16
@C.R.Helmrich
Could you add 12 kbps/channel mode?
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2020-12-05 16:40:37
The best option is b which you can get a 48kHz channel at 24kbps. Helmrich has repeatedly written that he doesn't have time to deal with the lower bitrates.
Title: Re: exhale - Open Source USAC encoder
Post by: jarsonic on 2020-12-08 18:50:22
Hey C.R. Helmrich,

Do you happen to know if the USAC / xHE-AAC spec supports multi-track encoding?  As in, shoving multiple tracks into a single output file?  If so, what might it take to have exhale support that?  Just curious.  :)

[edit:  I may have been doing some thing wrong before;  the first time I tried to encode multiple tracks as a single output file I got an error with exhale, but I tried again and it works.  :)  ]
Title: Re: exhale - Open Source USAC encoder
Post by: itisljar on 2020-12-09 08:26:34
Congratulation!
I've made quick ABX test of SBR, mode c encoding, and I can't distinguish two tracks, so I gave up :) maybe on some more critical tracks I could hear difference, this was type of music I usually listen when commuting, so it's good enough for that.
Title: Re: exhale - Open Source USAC encoder
Post by: dimonspb on 2020-12-20 12:30:06
Hello !
Prompt settings for work in Exact Audio Copy
Title: Re: exhale - Open Source USAC encoder
Post by: sld on 2020-12-22 12:36:26
The sound quality at ~40 kbps (mode a) is incredible.
Title: Re: exhale - Open Source USAC encoder
Post by: scharfis_brain on 2020-12-22 16:12:38
The sound quality at ~40 kbps (mode a) is incredible.
At least if you compare it to HE-ACC without ParametricStereo.

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

So I suspect lots of effort needs to be put into xHE-ACC to make it work more efficient than HE-ACCv2 (PS&SBR) at very low bitrates.
Title: Re: exhale - Open Source USAC encoder
Post by: IgorC on 2020-12-22 18:15:12
They sound only slightly worse than the 40kbps Exhale mode A encoding I made for comparison.
HE-AACv2, 24 kbps can only be on par with HE-AACv1 32 kbps. And it's already optimistic.

There is not  a single chance that HE-AACv2 24 kbps sounds only slightly worse than exhale ~40 kbps.
No.
 
Title: Re: exhale - Open Source USAC encoder
Post by: scharfis_brain on 2020-12-22 18:24:27
It only was a single sample I tested.  Maybe that sample was easy on HE-AACv2.
Title: Re: exhale - Open Source USAC encoder
Post by: itisljar on 2020-12-23 08:19:05
OK, today I was greeted with this error on Windows 10 machine; not exhale, but the decoder was the culprit:

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

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


So, what's up there?
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2020-12-23 08:33:13
Same here.
Title: Re: exhale - Open Source USAC encoder
Post by: Case on 2020-12-24 07:20:35
Might carry more weight to get kode54 to comment, but my simple analysis says it's a false positive. Those happen way too often.
There's another thread on the foobar2000 forum: https://hydrogenaud.io/index.php?topic=120328.0 (https://hydrogenaud.io/index.php?topic=120328.0).
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2020-12-24 08:23:48
I'm sure you're right, I was just confirming it wasn't a 'one off'. ;)
Title: Re: exhale - Open Source USAC encoder
Post by: AiZ on 2020-12-29 21:24:31
Hello,

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

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

    AiZ
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2020-12-29 22:00:50
Quickly spotted :) Yes, I just finished a 1.1.1 release candidate of exhale, see this commit (https://gitlab.com/ecodis/exhale/-/commit/b19ab84a). "3-subband SBR" means that that the SBR spectral range (11-16 kHz with 44.1 kHz sampling rate, e.g.) is now divided into 3 subbands, so the SBR frequency resolution increased compared to exhale 1.1.0. The bit allocation among these subbands is chosen optimally, but due to slightly more efficient coding of the SBR parameters, the overall bit-rates increased by only 0.1 kbit/s or so, even though we effectively now have two SBR frequency bands more.

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

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

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: IgorC on 2020-12-30 03:18:34
I am testing 1.1.0 and there is already 1.1.1    :-\
That's actually great :)

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

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


Title: Re: exhale - Open Source USAC encoder
Post by: m14u on 2020-12-30 04:51:00
mode 2@32khz do not work now (?). or do...
dont panic! release the Kraken! All work fine.
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2020-12-30 08:41:20
Intel compiles of exhale-develop-1.1.1rc-b19ab84a:

www.rarewares.org/files/aac/exhale-develop-1.1.1rc-b19ab84a_x64.zip (http://www.rarewares.org/files/aac/exhale-develop-1.1.1rc-b19ab84a_x64.zip)

www.rarewares.org/files/aac/exhale-develop-1.1.1rc-b19ab84a_x86.zip (http://www.rarewares.org/files/aac/exhale-develop-1.1.1rc-b19ab84a_x86.zip)

 :)
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2020-12-30 12:15:27
I am testing 1.1.0 and there is already 1.1.1    :-\
That's actually great :)
Great, thanks very much! Don't worry, your test won't be obsolete, the core coded signal below the SBR range hasn't changed at all since version 1.1.0. Which also means that all non-SBR modes (0-9) haven't changed. However, exhale 1.1.1 also includes a workaround for an issue discovered by celona (see here (https://hydrogenaud.io/index.php?topic=118888.msg990879#msg990879) and here (https://hydrogenaud.io/index.php?topic=118888.msg990992#msg990992), thanks to celona and kode54 for help in identifying this issue!). Therefore, I'm afraid I have to recommend to reencode your music even when not using SBR in order to prevent audio glitches under current Apple software versions.

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

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

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: IgorC on 2020-12-30 19:21:09
Chris, I don't see any image with red/green/blue.  Maybe it's just me.
Title: Re: exhale - Open Source USAC encoder
Post by: jaybeee on 2020-12-30 21:54:08
Chris, I don't see any image with red/green/blue.  Maybe it's just me.

Code: [Select]
http://www.ecodis.de/exhale111demo.png
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2020-12-30 22:20:22
Hmm, maybe it is blocked on your side because it's coming from http (and not https like this site). Anyway, I attached it here again for convenience.

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

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

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: capma on 2020-12-30 22:32:24
By the way, is anyone interested in faster xHE-AAC encoding? Something in the "10 times faster than the current exhale version" ballpark, with some slight losses in audio quality being acceptable?
Sure, why not :D Maybe merged with current exhale version, with quality switch to select speed or quality...
BTW, congratulations on the new version and thanks for NY present :)
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2020-12-30 23:01:00
Thanks, and you're very welcome :) Regarding my question, see this exhale Wiki entry (https://gitlab.com/ecodis/exhale/-/wikis/faq#why-is-the-exhale-encoder-so-slow-is-there-a-switch-for-fast-encoding), which explains how to compile exhale in a faster mode. Feel free to try it out and report your observations. On my laptop that version is about 5 times faster than the default compile. I don't want to offer a switch for this, though, since on some audio the quality degradation is quite noticeable.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: IgorC on 2020-12-31 00:19:43
@jaybeee @Chris
Thank You for the image.

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

xHE-AAC is meant to provide a better compression ratio comparing to LC/HE-AAC, even if it comes with speed penalty.  And, sincerely, today CPUs are fast enough. I get more than 100x speed with exhale on my laptop. 
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2020-12-31 01:45:57
However, exhale 1.1.1 also includes a workaround for an issue discovered by celona (see here (https://hydrogenaud.io/index.php?topic=118888.msg990879#msg990879) and here (https://hydrogenaud.io/index.php?topic=118888.msg990992#msg990992), thanks to celona and kode54 for help in identifying this issue!).

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

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

(http://www.paladino.ct.it/20201231.jpg)
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2020-12-31 04:08:07
exhale-develop-1.1.1-f1c25ea6_ARM.zip (http://www.paladino.ct.it/exhale-develop-1.1.1-f1c25ea6_ARM.zip)

exhale-develop-1.1.1-f1c25ea6_x64.zip (http://www.paladino.ct.it/exhale-develop-1.1.1-f1c25ea6_x64.zip)

Screenshot from macOS Terminal (http://www.paladino.ct.it/20201231.png)

Exhale in progress from a very cheap phone (http://www.paladino.ct.it/progress.jpg)
Title: Re: exhale - Open Source USAC encoder
Post by: Destroid on 2020-12-31 07:22:22
@celona

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

@C.R.Helmrich
As you know, I'm a speed-freak when dealing with encoders :) But with exhale I think slower (quality) makes the most sense. (But I'd really like to try benching some non-trellis x86 compiles :) :) )
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2020-12-31 09:30:49
On the one hand you get a faster encoding on the other hand  somebody will use it in his/her applications without even knowing it and a lot of people will end with a lower audio quality.
Exactly, and that's what I'm trying to avoid. So having that compiler macro as a solution seems the best approach to me.

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

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

Happy New Year to everyone!

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2020-12-31 10:28:19
Intel compiles of exhale-v.1.1.1-36964d20 are now at Rarewares. :)
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2020-12-31 10:46:58
That ARM demo is amazing :) Now l have to learn to get a terminal emulator running on Android in order to try this.

https://termux.com
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2020-12-31 11:16:58
exhale v1.1.1-36964d20 (Stable)
Built on December 31, 2020, GCC 10.2.0
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2020-12-31 13:08:04
exhale v1.1.1-36964d20_macOS_ARM.zip (http://www.paladino.ct.it/exhale v1.1.1-36964d20_macOS_ARM.zip)

@Destroid Here is the release used for Android test

exhale-develop-1.1.1-f1c25ea6_Android.zip (http://www.paladino.ct.it/exhale-develop-1.1.1-f1c25ea6_Android.zip)
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2020-12-31 14:58:47
I forgot this:
exhale%20v1.1.1-36964d20_macOS_x64.zip (http://www.paladino.ct.it/exhale%20v1.1.1-36964d20_macOS_x64.zip)
Title: Re: exhale - Open Source USAC encoder
Post by: itisljar on 2020-12-31 17:54:26
And, sincerely, today CPUs are fast enough. I get more than 100x speed with exhale on my laptop. 

What, on single core?
Title: Re: exhale - Open Source USAC encoder
Post by: capma on 2020-12-31 19:29:25
Not in my case... one zero less :) 10.6x, to be exact, when encoding to preset 3.
Title: Re: exhale - Open Source USAC encoder
Post by: jarsonic on 2020-12-31 20:25:08
yeah, I get about 16x from a moderately spec'd thinkpad from 2 years ago.
Title: Re: exhale - Open Source USAC encoder
Post by: IgorC on 2020-12-31 22:00:41
What, on single core?
6 cores / 12 threads
Title: Re: exhale - Open Source USAC encoder
Post by: Destroid on 2021-01-01 10:06:20
@celona
Awesome and thanks :) I'll try this out for sure.

Not to forget a Happy New Year to CRHelmrich, john33, IgorC, and so many HA fans that would fill a book. :)

Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-01-14 00:00:32
fyi, an xHE-AAC demo page (not related to exhale, though):

 https://www2.iis.fraunhofer.de/AAC/xhe-aac-compare-tab.html

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-01-14 18:18:35
After trying Exhale on macOS with ARM SoC and on Android, it's Linux's turn and I have compiled Exhale on Raspberry Pi 4, without errors or warnings.

Exhale-master-1.1.1-36964d20-Linux-ARM.zip (http://www.paladino.ct.it/exhale-master-1.1.1-36964d20-Linux-ARM.zip)
Title: Re: exhale - Open Source USAC encoder
Post by: diizzy on 2021-01-16 10:57:26
If you want to make exhale more accessable please submit a proper package build to a distribution's package repo instead of posting random builds/binaries. Repology looks very sparse in that regard, https://repology.org/project/exhale/versions
Title: Re: exhale - Open Source USAC encoder
Post by: itisljar on 2021-01-17 10:58:26
Still nothing from ffmpeg people? At least decoder...?
Title: Re: exhale - Open Source USAC encoder
Post by: hyaudio on 2021-01-17 13:57:04
fyi, an xHE-AAC demo page (not related to exhale, though):

 https://www2.iis.fraunhofer.de/AAC/xhe-aac-compare-tab.html

Chris

Not HE-AACv2, but HE-AACv1 was used.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-01-17 14:14:18
How do you know? Apparently it's not written anywhere, and if I listen to e.g. Music: "Walking", the 16-kbps HE-AAC version sounds to me like Parametric Stereo of v2 is being used. On the higher bitrates you're probably right, but there it may make sense not to use Parametric Stereo.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: IgorC on 2021-01-22 01:11:20
News:
Netflix Now Streaming xHE-AAC Audio on Android Mobile (https://www.design-reuse.com/news/49293/netflix-fraunhofer-iis-xhe-aac-audio-codec-android-mobile.html)

I wonder whether Netflix uses exhale or some commercial encoder by FhG.
Title: Re: exhale - Open Source USAC encoder
Post by: jaybeee on 2021-01-22 11:42:34
Thanks for the info IgorC. Good to know.

Surely Netflix will be using Fraunhofer's encoder since Fraunhofer announced it though.
And "Netflix has licensed Fraunhofer’s high-quality xHE-AAC software". I don't think they'd pay for a license and then end up using a free version of the encoder. But damn, that would be a cool story if so lol.



Title: Re: exhale - Open Source USAC encoder
Post by: binaryhermit on 2021-01-22 17:04:13
I mean, they would still presumably have to license the relevant patents?
Title: Re: exhale - Open Source USAC encoder
Post by: jaybeee on 2021-01-22 17:48:09
I mean, they would still presumably have to license the relevant patents?
I have zero knowledge of license and patent requirements etc wrt audio codecs and encoders etc. Logically though, it leads me to ask if a patent is required then how can we use exhale? But is that because we do so for personal / non-commercial purposes? I guess it's the same for mp3 encoders.

I await to be schooled on this matter lol
Title: Re: exhale - Open Source USAC encoder
Post by: binaryhermit on 2021-01-22 19:01:46
Depending on the exact terms of the AAC patent license you might not be able to (legally), that's how it was until the last MP3 patent expired in 2017.

But there's significant effort and general lack of reward for going after little guy end users for this.

Plus the proliferation of "illegally encoded" mp3s made mp3 what it was to the point where a device that didn't decode mp3s was effectively seen as defective, which allowed them to collect money for legally licensed mp3 decoders from the big  hardware and software players like Apple, Microsoft, etc.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-01-23 01:42:30
News:
Netflix Now Streaming xHE-AAC Audio on Android Mobile (https://www.design-reuse.com/news/49293/netflix-fraunhofer-iis-xhe-aac-audio-codec-android-mobile.html)

I wonder whether Netflix uses exhale or some commercial encoder by FhG.
I mean, they would still presumably have to license the relevant patents?
There's a Netflix blog post (https://netflixtechblog.com/optimizing-the-aural-experience-on-android-devices-with-xhe-aac-c27714292a33) which states that "content was encoded using the xHE-AAC encoder provided by Fraunhofer IIS", and the news article that Igor linked to says that "Netflix has licensed Fraunhofer's high-quality xHE-AAC software". Which likely means they licensed the usage rights (i.e., relevant patents) along with it.

Regarding exhale, I just finished a 1.1.2 beta without changes to the audio quality but hopefully somewhat better compatibility with some players/devices. You can find it on Git branch develop_ipf (https://gitlab.com/ecodis/exhale/-/tree/develop_ipf), revision 193dc26. Please report any regressions regarding gapless playback, seeking, or similar issues.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2021-01-23 09:21:35
exhale v1.1.2-193dc268 (BETA)
Built on January 23, 2021, GCC 10.2.0

NOTE :
The version is still shown as v1.1.1 when using -V/--version
Title: Re: exhale - Open Source USAC encoder
Post by: binaryhermit on 2021-01-23 12:46:50
What I said regarding the patents was if they were using exhale.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-01-23 17:23:16
The version is still shown as v1.1.1 when using -V/--version
Indeed, I updated the year but forgot the version number. Fixed, along with some other minor things. Please continue testing with the new revision 9ed76ef, which I consider a first 1.1.2 release candidate.

What I said regarding the patents was if they were using exhale.
Well, I'm not a patent/copyright lawyer, but exhale's license (http://www.ecodis.de/exhale/license.htm) contains a "no patents granted" disclaimer similar to most publicly available MPEG audio or video coding software. I believe that disclaimer answers your question.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: jaybeee on 2021-01-23 17:54:25
Thanks Chris. Reading exhale's license (http://www.ecodis.de/exhale/license.htm) has a link to Via Licensing (https://www.via-corp.com/) and their FAQ (https://www.via-corp.com/licensing/aac/aac-faqs/) states:

Quote from: Via Licensing
Who must sign a license?
An AAC patent license is needed by manufacturers or developers of end-user encoder and/or decoder products.
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2021-01-23 20:33:40
exhale vexhale v1.1.2-9ed76efe (RC1)
Built on January 23, 2021, GCC 10.2.0
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-01-24 01:40:01
What I said regarding the patents was if they were using exhale.

You can search for any licensee on the Via website (https://www.via-corp.com/licensing/aac/licensees/) and buy from whoever sells you the encoder. If I can spare you the trouble, I bought the Exhale encoder included in one of its products from Poikosoft to avoid any legal problems. Find it here:
https://www.poikosoft.com/music-converter
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-01-24 02:08:40
Exhale commit 44f6b15b for macOS (64 bit for Intel processors and ARM SoCs) and for Linux ARM SoCs (http://www.paladino.ct.it/44f6b15b.zip).
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2021-01-24 17:14:28
exhale v1.1.2-44f6b15b (RC2)
Built on January 24, 2021, GCC 10.2.0
Title: Re: exhale - Open Source USAC encoder
Post by: m14u on 2021-01-26 11:23:45
develop_ipf_0b14fafc_finish_1.1.2_release
random search noise in [a..g] modes
Title: Re: exhale - Open Source USAC encoder
Post by: m14u on 2021-01-26 13:08:24
this "bug" can be traced from the very appearance of the [a..g] modes (exhale-develop_v1.1a_2020-11-10_1259070c)
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-01-27 00:01:42
What you're describing sounds like what guruboolez first reported here (https://hydrogenaud.io/index.php?topic=118888.msg990385#msg990385). See also this post (https://hydrogenaud.io/index.php?topic=118888.msg990700#msg990700) and the following comment by kode54. Nothing I can do about that in exhale (unfortunately... I actually tried improving on that issue with commit 44f6b15b to develop_ipf, but it doesn't make a difference).

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: m14u on 2021-01-27 08:19:49
ok. not a "bug" - "feature". it does not affect normal listening. sorry for the "panic".
Title: Re: exhale - Open Source USAC encoder
Post by: jdimsa on 2021-01-28 03:58:08
xHE-AAC is audibly non-transparent even at mode 9 in my ABX tests. Does this codec only aim for good quality at low bitrates, or are there plans to make it better for high bitrate transparency in the future?
Title: Re: exhale - Open Source USAC encoder
Post by: [JAZ] on 2021-01-28 19:33:17
@jdimsa: Don't you think that if you make that bold statement, you should also give an explanation of what is wrong, and since you did some ABX tests, also attach them?

Else, it doesn't help at all to improve anything that could need improvement.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-01-28 23:28:09
Does this codec only aim for good quality at low bitrates, or are there plans to make it better for high bitrate transparency in the future?
That depends on whether the issue you hear is the result of, well, insufficiently sophisticated encoding, or a bug. From previous test reports, transparency at CVBR mode 9 (~192 kbit/s) is not guaranteed, as the following estimate (http://www.ecodis.de/audio/exhale_quality_estim.png) (which I posted previously) shows.

Notice how the estimation curve and the actual data value around 192 kbit/s are below 5.0 (5 = acoustic transparency even in ABX tests).

If there's a sample on which you hear obvious artifacts even at mode 9, yes, please link to it here and mention the time range where you hear the artifact, so I can take a look at it.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: jdimsa on 2021-01-29 01:22:16
:



If there's a sample on which you hear obvious artifacts even at mode 9, yes, please link to it here and mention the time range where you hear the artifact, so I can take a look at it.

Chris

I wouldn't say obvious artifacts; mode 9 quality is very solid. But I can definitely detect the typical shortcomings of insufficient lossy encoding such as the shimmering sound from a cymbal not being perfectly reproduced, which Apple Q109 does manage.
Title: Re: exhale - Open Source USAC encoder
Post by: jaybeee on 2021-01-29 11:30:12
@jdimsa: ... and since you did some ABX tests, also attach them?

Else, it doesn't help at all to improve anything that could need improvement.

:



If there's a sample on which you hear obvious artifacts even at mode 9, yes, please link to it here and mention the time range where you hear the artifact, so I can take a look at it.

Chris

I wouldn't say obvious artifacts; mode 9 quality is very solid. But I can definitely detect the typical shortcomings of insufficient lossy encoding such as the shimmering sound from a cymbal not being perfectly reproduced, which Apple Q109 does manage.

Please post an ABX log and also supply Chris with the audio track that you've identified the issue with. Chris is here and willing to investigate if there is an issue and potentially fix it (if appropriate).
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2021-01-29 12:39:25
exhale v1.1.2-0b14fafc (RC3)
Built on January 29, 2021, GCC 10.2.0
Title: Re: exhale - Open Source USAC encoder
Post by: jdimsa on 2021-01-30 04:18:42
Again, I don't believe what I'm hearing are obvious artifacts due to a bug, it's just the extremely subtle difference caused by insufficiently sophisticated encoding. Nonetheless, I went back and did more testing, and found that I could pick mode 8 very easily (8/8 in only 3 minutes). I did 16 runs for mode 9 to be more thorough, and got 13/16 (although I kinda rushed through mode 9 as well, only spending 10 minutes total). I'm not sure if 13/16 is a high enough score to be a statistically significant sign of actually having spotted the difference (when you consider the base level score you are likely to get from the chance of picking the right one by accident), or if I just got lucky, however I'm fairly confident I was able to hear a more subtle version of the same artifact(s) that were immediately apparent in mode 8.

The main difference I notice is at the 900 millisecond mark in the sample, where the lyric "just" has one of those MP3-style artifacts on it (not sure how to describe). The cymbals that come half a second later also sound different, and "cut" or "roll off" sooner in the xHE-AAC version.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-01-30 10:50:25
Thanks for the files. Technically, the mode 9.m4a looks perfectly fine. Could it be that your high-frequency hearing (above ~17 kHz with normal music, not pure tones) is exceptionally good? And to rule out any playback related issues: which decoder did you use? Foobar2000 with kode54's packet decoder?

Getting 13/16 on mode 9 is actually not that unusual, I'd say. Igor's 2020 test showed already that exhale scores with an average MOS of about 4.9 out of 5, see also the image I posted above.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: [JAZ] on 2021-01-30 11:00:15
 :o :-[
I believe I'm out for helping on this...

I can only hear the difference in the "just" word that you mention at preset 1 (67kbps) and by paying attention (I didn't even realize at first, although once detected, I can focus on it).
preset 5 (128kbps) is already difficult for me to distinguish.

Tried a-g on this sample and, to me, even preset a (40kbps) sounds fantastic (not transparent, obviously, but good, and that's without resampling to 32Khz which is supposed to improve the quality). I can only discern differences in stereo imaging in the cymbals, and probably some preecho, which is considerably reduced at c (64kbps). And, of course, the difference in the "just" word.
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2021-01-30 20:53:07
exhale v1.1.2-7a2c4048
Built on January 30, 2021, GCC 10.2.0
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-01-30 23:10:53
Thanks, JAZ, for having a second listen. And of course to jdimsa for reporting this. I'm sorry, but there's not much I can do here. Meanwhile,

exhale 1.1.2 has been released.

Changes since exhale 1.1.1 from last month:

Compared to NetRanger's last RC, there is only a slight stabilization for strongly out-of-phase input (which should occur very rarely, if at all) at CVBR modes 5 and above.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2021-01-31 01:42:38
Thnx for the new release Chris :)

exhale v1.1.2-7d2b818e (Stable)
Built on January 31, 2021, GCC 10.2.0
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-01-31 04:18:17
Excellent. I haven't actually tried ABX comparisons, but find both the 3 and c modes to be not-annoying and therefore passablefor compact distribution or otherwise just casual listening.

FYI RhythmBox on Linux is a passable player for these, if the local GStreamer happens to have FDK support enabled, like on Arch. No seeking support whatsoever yet, but at least they play without much fiddling!

Here, have some macOS dual arch (x86 64+arm64) binaries, signed and notarized:

https://f.losno.co/exhale-v1.1.2-0-g7d2b818.zip
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2021-01-31 09:09:59
exhale v1.1.2-7 Release-d2b818e Intel compiles are now on Rarewares. ;)
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-02-01 00:58:33
-7? But it's 0 commits past the 1.1.2 tag. The 7 is the first digit of the commit hash.
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2021-02-01 07:54:22
Oops!! It's correct on Rarewares, just a 'typo' on the post above! It should, of course, read:

exhale v1.1.2-Release-7d2b818e Intel compiles are now on Rarewares.

Apologies for any confusion caused. ;)
Title: Re: exhale - Open Source USAC encoder
Post by: fabiorug on 2021-02-02 21:21:56
Do you still have compiles for windows for exhale-develop-1.1.0rc4-c71ec480? Which bitrate is stereo SBR (d preset) for that commit?
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2021-02-03 08:44:33
Yes, I do. You want them made available?

Edit: The links here: https://hydrogenaud.io/index.php?topic=118888.msg990984#msg990984 (https://hydrogenaud.io/index.php?topic=118888.msg990984#msg990984) are still valid. ;)
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-02-03 23:45:12
From the tests I did exhale works practically everywhere, below I leave you the binary (last commit) for Linux on armv6l:
exhale.gz (http://www.paladino.ct.it/exhale.gz) - update: download video (http://www.paladino.ct.it/20210204.m4v).

From a practical standpoint it means that your router or powerline adapter could compress a monaural audio file into about 50% of its playing time. I have no ideas about possible uses, but these SBCs cost very little, in Europe they can be bought for less than 6 euros including taxes and perhaps one of the easiest to find is the Raspberry PI Zero (https://www.raspberrypi.org/products/raspberry-pi-zero/), with 1GHz single-core CPU, 512MB RAM and works also as a USB gadget.

These are SoC very popular in the past, the armv6 architecture is the same as the first iPod touch, the first iPhone, the second and 3G too.
Title: Re: exhale - Open Source USAC encoder
Post by: scharfis_brain on 2021-02-14 18:05:37
Compared to NetRanger's last RC, there is only a slight stabilization for strongly out-of-phase input (which should occur very rarely, if at all) at CVBR modes 5 and above.

Nowadays lots of Stereo-sources are Dolby-Surround coded, which means that all back facing sounds are 180° phase shifted between L an R channels.
So I really doubt that out of phase contents are a rare condition. They are commonplace.
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-02-15 00:12:30
Must be really fun listening to crap like that on headphones, like I usually do.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-02-28 18:09:37
Indeed. scharfis_brain, is Dolby Surround encoded stereo audio still really that commonplace? The last audio CD in my collection on which I saw that (German band Schiller) is 20 years old.

I just released a relatively urgent release candidate of exhale 1.1.3 which, hopefully, improves the compatibility of exhale generated .m4a files a bit more. See this commit (https://gitlab.com/ecodis/exhale/-/commit/8cdc188). Please let me know as soon as possible whether there are any compilation or stdin-encoding or playback related issues on any platforms.

Update: To everyone using (or thinking about using) exhale to generate xHE-AAC files for streaming applications: apart from fixing the generation of immediate playout frames (IPFs) once more, this version allows you to specify a program loudness (LUFS) and sample peak (dBFS) level as additional command-line arguments between the existing preset and file arguments. Note that, when doing so, you need to specify both, the LUFS and dBFS value (if you don't have the peak sample value, I guess you can use something like -0.01).

Example: for encoding with SBR at ~48 kbit/s stereo and with the input audio (here, WAVE file inStereo.wav) having loudness level -12.34 LUFS and sample peak level -0.123 dBFS, use
"exhale.exe b -12.34 -0.123 inStereo.wav outStereo.m4a"
or, when using stdin (e.g. via foobar2000) instead of file based encoding,
"exhale.exe b -12.34 -0.123 outStereo.m4a"
On operating systems other than Windows, adjust the spelling of "exhale.exe" accordingly.

This feature allows you to encapsulate proper loudness information even in the IPFs, which is important for streaming applications where the receiver can tune in to the stream at any time (i.e., any IPF) and cannot rely on the MPEG-4 file header. It is also beneficial for offline use cases such as file based encoding for personal archiving purposes, in order for the loudness information in the IPFs to match that in the MPEG-4 header (which always contains the actual audio loudness and peak sample level measured by exhale during encoding). So you need to make sure that the LUFS/dBFS values that you pass to the exhale application math those reported by the application once the encoding is complete.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-03-01 19:05:28
The commit 8cdc188b compiles without errors on Linux and macOS (I have tested only for armv7l and arm64).
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2021-03-01 22:31:37
exhale v1.1.3-8cdc188b (Stable)
Built on March 01, 2021, GCC 10.2.0

https://gitlab.com/ecodis/exhale
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2021-03-02 08:33:00
Intel compiles of exhale-v1.1.3-8cdc188b now at Rarewares. (Compiles cleanly with no errors. ;))
Title: Re: exhale - Open Source USAC encoder
Post by: andrew.46 on 2021-03-03 08:50:09
Compiled and ran well on Slackware Linux:

Code: [Select]
andrew@ilium/mnt/ssd2/luckynight$ exhale b -12.34 -0.123 luckynight.wav outStereo.m4a

  ---------------------------------------------------------------------
 | exhale - ecodis extended high-efficiency and low-complexity encoder |
 |                                                                     |
 | version 1.1.3 (x64, built on Mar  3 2021) - written by C.R.Helmrich |
  ---------------------------------------------------------------------

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

 Progress: ----------------- Done, actual average incl. SBR data 54.08 kbit/s

 Input statistics:  File loudness -14.94 LUFS, sample peak level -0.20 dBFS

andrew@ilium/mnt/ssd2/luckynight$

Now if only standard Linux players could come at this.... but I am still excited to see the files being produced with an Open Source application :)
Title: Re: exhale - Open Source USAC encoder
Post by: itisljar on 2021-03-04 08:29:56
exhale v1.1.3-8cdc188b (Stable)
Built on March 01, 2021, GCC 10.2.0

https://gitlab.com/ecodis/exhale

This one was a second faster than Intel compiled one on Ryzen 5 3600, for a song that lasts 10:38. So, for a whole album there would be around 6-7 seconds difference. Not a thing to be concerned by... except if you want to encode your whole collection :)
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-03-04 22:30:51
There is one Linux player that already has native support, or at least two. Rhythmbox, assuming your copy of GStreamer was built with libfdkaac support. Or Gnome's generically named music player, I forget its name.

Neither player will support seeking USAC right now, though.
Title: Re: exhale - Open Source USAC encoder
Post by: Destroid on 2021-03-05 08:11:53
@itisljar

Are you running 64-bit?
Title: Re: exhale - Open Source USAC encoder
Post by: andrew.46 on 2021-03-05 08:22:02
There is one Linux player that already has native support, or at least two. Rhythmbox, assuming your copy of GStreamer was built with libfdkaac support. Or Gnome's generically named music player, I forget its name.

And now you have jogged my old memory I remember that FFpaly will also play these files back by specifying libfdk_aac as the audio codec on the command line...

Title: Re: exhale - Open Source USAC encoder
Post by: itisljar on 2021-03-05 09:19:43
@itisljar
Are you running 64-bit?

Who runs 32 bit in this day and age? (Well, I guess there are some people that HAS TO...)
64 bit OS, 64 bit encoders. Why? Are 32 bit faster?
Title: Re: exhale - Open Source USAC encoder
Post by: mycroft on 2021-03-06 12:01:02
All those players and encoder implementations are violating numerous patents.
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-03-06 14:02:47
Not necessarily, if you go back in the discussion you will find that I have paid the license to be able to distribute the compressed files to third parties without problems but nothing prevents you from compiling the software for personal use and evaluating the final compression and decompression performance.

For example, Exhale is distributed in source code form. You must have the software to compile it and in many cases you will have to compile the decoder as well, with the risk of failing. This does not affect the rights of the patent holders.

If you use Linux, Windows or other operating systems without the decoder you will have to compile a program built with libfdk_aac support, as suggested by kode54 (https://hydrogenaud.io/index.php?topic=118888.msg994489#msg994489), and I honestly, I still can't.

In my opinion, buying a software that performs this task is the simplest choice to make, even if there is not a wide choice.

Sometimes even after paying for the software new needs arise, for example I also bought Exhale together with https://www.poikosoft.com/music-converter (https://www.poikosoft.com/music-converter) which only works with Windows, while now I'm using Linux. I can download Exhale and compile it for Linux relatively easily.

The tricky part is being able to hear the compressed files; to achieve the purpose I can use the command line to get libfdk_aac:
Code: [Select]
mkdir ~ / fdk-aac
git clone --depth 1 https://github.com/mstorsjo/fdk-aac.git ~ / fdk-aac \
  && cd ~ / fdk-aac \
  && autoreconf -fiv \
  && ./configure \
  && make -j $ (nproc) \
  && sudo make install

After this step all that remains is to compile ffmpeg with the fdk-aac library so that you can play the files with the command:
Code: [Select]
ffplay -acodec libfdk_aac your_file_name.m4a

In my opinion you have to try, but really, surely afterwards you will enjoy paying those who offer you a solution in exchange for money much more.

I believe that in this place the interests of those who write the software meet with the passion of those who want to use it, no one harms the others and not even the patent holders. Thinking that it is easier to pay only with your time what costs a few dollars is equivalent to giving zero value to your time (which is a non-renewable resource for anyone) and also to your skills.
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-03-07 00:17:23
All those players and encoder implementations are violating numerous patents.
Maybe they'll start caring when someone actually comes after people with lawsuits.

P.S. It may be worth moving all hosting to France, where there's none of this software patent rubbish.
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2021-03-07 01:33:02
exhale v1.1.3-2d0fa2f1
Built on March 07, 2021, GCC 10.2.0

https://gitlab.com/ecodis/exhale
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-03-07 03:37:48
exhale-2d0fa2f1 Linux armv7 (https://hydrogenaud.io/index.php?action=dlattach;sa=tmpattach;attach=19125;topic=118888)

This version increases the bitrate needed to encode the human voice. I have add 1 min of Italian speech recorded simultaneously with two different microphones by a professional (with some tics), the Neumann U87 Ai (https://en-de.neumann.com/u-87-ai) (called U87AI) and sE Electronics X1 T (https://www.seelectronics.com/se-x1-t-tube-mic) (called sEX1T).

U87AI.wav (https://hydrogenaud.io/index.php?action=dlattach;sa=tmpattach;attach=post_tmp_134208_8bb837e4258d54906ad573d9cd1b6fc9;topic=118888) | U87AI.opus (https://hydrogenaud.io/index.php?action=dlattach;sa=tmpattach;attach=post_tmp_134208_75d11a376d0d380ccce0591cf6f9b795;topic=118888) | U87AI.m4a (b) (https://hydrogenaud.io/index.php?action=dlattach;sa=tmpattach;attach=post_tmp_134208_fc18011c53e43b3a76877d3dd21231be;topic=118888) | U87AI.m4a (b) (https://hydrogenaud.io/index.php?action=dlattach;sa=tmpattach;attach=post_tmp_134208_b29e2217c0653aaf9f2c33fc183e4b0b;topic=118888)

sEX1T.wav (https://hydrogenaud.io/index.php?action=dlattach;sa=tmpattach;attach=post_tmp_134208_cb9c84a5fc50789c6c3d8f417ca717d7;topic=118888) | sEX1T.opus (https://hydrogenaud.io/index.php?action=dlattach;sa=tmpattach;attach=post_tmp_134208_858103239c55474025b1b758c329c7eb;topic=118888) | sEX1T.m4a (b) (https://hydrogenaud.io/index.php?action=dlattach;sa=tmpattach;attach=19127;topic=118888)

Only the sEX1T.m4a file was compressed with Exhale commit 2d0fa2f1. The problem is not the increasing bitrate but the voice quality which cannot be so compromised with option b. Even in modes without SBR it is useful to have the zero option which sacrifices too much quality to contain space but IMHO not the others too. I added Opus at 24kbps (SILK + CELT).
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2021-03-07 11:59:34
exhale v1.1.3-2d0fa2f1 Intel compiles now at Rarewares.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-03-07 12:27:53
Sorry, celona, I don't fully understand your previous post. Are you saying that version 2d0fa... makes voice sound worse than release 1.1.3 in the SBR modes?

This one was a second faster than Intel compiled one on Ryzen 5 3600, for a song that lasts 10:38. So, for a whole album there would be around 6-7 seconds difference. Not a thing to be concerned by...
Indeed. It seems that, for noticeable speed-ups, "manual magic SIMD code" from (if memory serves) experts like Saratoga and lvqcl would be required.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-03-07 14:25:13
Sorry, celona, I don't fully understand your previous post. Are you saying that version 2d0fa... makes voice sound worse than release 1.1.3 in the SBR modes?

I apologize, I was unclear, the problem also exists in previous versions, Exhale can be a valid tool to contain space and preserve good quality of music, but it doesn't work as well with low bitrate voice alone (24kbps was a declared goal of the developer). A slightly different strategy is needed to make sense of this encoder which has the advantage of being standardized by ISO at bitrate where it competes with telephony encoders, which unlike xHE-AAC (or USAC) cannot be used with the HTML5 <audio> tag . I will write here later to give you some ideas and some numbers.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-03-07 15:12:55
Thanks for the clarification. Please remember that exhale does not implement USAC's speech coding part (ACELP/TCX). To reference myself from the early days of this thread: https://hydrogenaud.io/index.php?topic=118888.msg980837#msg980837
Quote
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 (ACELP, TCX, ...) 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.

Meanwhile I tested your files myself, and the current version increases the bit-rate by only ~0.3 kbps.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: andrew.46 on 2021-03-09 01:06:13
Linux users may be interested to know that I have reworked my exhale patch against the current git of the audio CD ripper abcde. Tested it and it all works very, very well. Details published here;

abcde: Ripping to AAC...
https://www.andrews-corner.org/abcde/abcde_aac.html#exhale

I am aware that the exhale default options are quite conservative but these are very easily tweaked by an enthusiastic user :)
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2021-03-10 23:52:12
exhale v1.1.3-0bde366c
Built on March 10, 2021, GCC 10.2.0

https://gitlab.com/ecodis/exhale
Title: Re: exhale - Open Source USAC encoder
Post by: andrew.46 on 2021-03-11 06:20:11
I compiled gst-plugins-bad 1.18.3 on my Slackware system, picking up fdkaac, and this has certainly opened up a swag of media players under Linux as Kode54 has mentioned. Please pardon my obvious ignorance of this, I have never really been a gstreamer sort of guy...

Tested so far successfully on a native Linux install have been:


I have not tested any further but it would be interesting to see how many more media players on this list (https://gstreamer.freedesktop.org/apps/) are successful with exhale output playback...

Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-03-12 21:30:20
Thanks very much, Andrew, for the update and the testing! I just cleaned up exhale's source code a bit. Please forget about the additional command-line parameters I introduced with the last release, it should not be necessary anymore to specify any LUFS/peak sample values manually, exhale calculates these values automatically and now also writes these values automatically to all IPFs.

Consider the current revision (https://gitlab.com/ecodis/exhale/-/commit/5bfcbaca) in exhale's main Git branch an early exhale 1.1.4 beta release. The output of that revision should be identical to that of the revision which NetRanger compiled above. Please report any issues you encounter with the 1.1.4 beta.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-03-12 23:35:50
This version looks much better; the previous one did not downsample to 32kHz at lower bitrates, now it works fine.
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-03-13 02:23:17
New versions compiled for ARM SoC: exhale@5bfcbaca for Linux armv7l (http://www.paladino.ct.it/exhale/exhale@5bfcbaca.bz2) | exhale@5bfcbaca for macOS arm64 (http://www.paladino.ct.it/exhale/exhale@5bfcbaca.zip) .

I have to change my mind about the fact that the new version works well, it still has the problems of the previous. I have made a 15s track from YouTube (https://youtu.be/eiDiKwbGfIY). In this case we have a treated recording and the microphone is not a cheap model with self-noise present in the track, a Ribera R47 (https://www.audioribera.it/microphones/ribera-r47/) was used.

The result is better than the previous speech, we have a male voice that sings in Italian (the language affects the artifacts, I skipped the English part). In my opinion is excellent. So I show you the bug that I found providing the files to use in inputs to obtain it easily.

Perfect symphony (Ed Sheeran and Andrea Bocelli) - stereo - sampling rate 48kHz (http://www.paladino.ct.it/exhale/Perfect symphony-48kHz.wav) | 44,1kHz (http://www.paladino.ct.it/exhale/Perfect symphony-44kHz.wav) | 32kHz (http://www.paladino.ct.it/exhale/Perfect symphony-32kHz.wav) | 24kHz (http://www.paladino.ct.it/exhale/Perfect symphony-24kHz.wav)

Exhale mode 0

Exhale mode 1

It could have been written simply but I preferred to schematically show the steps I took.

Below are the results obtained with exhale@5bfcbaca mode 0 (http://www.paladino.ct.it/exhale/Perfect symphony-0.m4a) | 1 (http://www.paladino.ct.it/exhale/Perfect symphony-1.m4a) | 2 (http://www.paladino.ct.it/exhale/Perfect symphony-2.m4a) | 3 (http://www.paladino.ct.it/exhale/Perfect symphony-3.m4a) | 4 (http://www.paladino.ct.it/exhale/Perfect symphony-4.m4a) | 5 (http://www.paladino.ct.it/exhale/Perfect symphony-5.m4a) | 6 (http://www.paladino.ct.it/exhale/Perfect symphony-6.m4a) | 7 (http://www.paladino.ct.it/exhale/Perfect symphony-7.m4a) | 8 (http://www.paladino.ct.it/exhale/Perfect symphony-8.m4a) | 9 (http://www.paladino.ct.it/exhale/Perfect symphony-9.m4a) | a (http://www.paladino.ct.it/exhale/Perfect symphony-a.m4a) | b (http://www.paladino.ct.it/exhale/Perfect symphony-b.m4a) | c (http://www.paladino.ct.it/exhale/Perfect symphony-c.m4a) | d (http://www.paladino.ct.it/exhale/Perfect symphony-d.m4a) | e (http://www.paladino.ct.it/exhale/Perfect symphony-e.m4a) | f (http://www.paladino.ct.it/exhale/Perfect symphony-f.m4a) | g (http://www.paladino.ct.it/exhale/Perfect symphony-g.m4a) .
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-03-13 04:00:31
Previous recording (http://www.paladino.ct.it/exhale/U87AI.wav) of a male voice spoken in front of a Neumann U87 Ai (https://en-de.neumann.com/u-87-ai) that showing artifacts on the first syllable.

The results obtained with exhale@5bfcbaca mode 0 (http://www.paladino.ct.it/exhale/U87AI-48kHz-0.m4a) | 1 (http://www.paladino.ct.it/exhale/U87AI-48kHz-1.m4a) | 2 (http://www.paladino.ct.it/exhale/U87AI-48kHz-2.m4a) | 3 (http://www.paladino.ct.it/exhale/U87AI-48kHz-3.m4a) | 4 (http://www.paladino.ct.it/exhale/U87AI-48kHz-4.m4a) | 5 (http://www.paladino.ct.it/exhale/U87AI-48kHz-5.m4a) | 6 (http://www.paladino.ct.it/exhale/U87AI-48kHz-6.m4a) | 7 (http://www.paladino.ct.it/exhale/U87AI-48kHz-7.m4a) | 8 (http://www.paladino.ct.it/exhale/U87AI-48kHz-8.m4a) | 9 (http://www.paladino.ct.it/exhale/U87AI-48kHz-9.m4a) | a (http://www.paladino.ct.it/exhale/U87AI-48kHz-a.m4a) | b (http://www.paladino.ct.it/exhale/U87AI-48kHz-b.m4a) | c (http://www.paladino.ct.it/exhale/U87AI-48kHz-c.m4a) | d (http://www.paladino.ct.it/exhale/U87AI-48kHz-d.m4a) | e (http://www.paladino.ct.it/exhale/U87AI-48kHz-e.m4a) | f (http://www.paladino.ct.it/exhale/U87AI-48kHz-f.m4a) | g (http://www.paladino.ct.it/exhale/U87AI-48kHz-g.m4a) .

Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2021-03-13 15:24:27
exhale v1.1.4-5bfcbaca {BETA1}
Built on March 13, 2021, GCC 10.2.0

https://gitlab.com/ecodis/exhale
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-03-14 11:09:03
the previous one did not downsample to 32kHz at lower bitrates, now it works fine.
...
input file sampled at 44,1kHz, I read on the screen "ERROR during encoding! Input sample rate must be <=32 kHz for preset mode 0!" and I get nothing;
input file sampled at 48kHz, I read on the screen "Encoding 32-kHz" and I get a 32kHz sampled file.
That error is a feature, not a bug. I found a 44.1-to-32-kHz downsampler to be too much work (48-to-32, i.e. 3:2 downsampling is much easier and faster) and didn't implement it. After all, you can use foobar2000's resampler DSP to do that on-the-fly.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: wyup on 2021-03-14 12:41:48
I'd like to thank Chris for his amazing work in audio and his xHE implementation by sharing a music sample from a performance that I recorded live at the venue from the audience with my phone, it's the Mozart Quintet K.452. I have it cut, DC-centered, stereo normalized and adjusted for EBU R-128 loudness at -23 LUFS lossless.
It is amazing how a 25-min concert fits in a ~6 Mb file with lowest SBR encoding at 34 kbps. It sounds quite good on my desktop gear, and I can share it in Whatsapp with direct preview from the chat screen on the phone, thanks to included codec since Android 9 and IOS 13 (2019).
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-03-14 15:01:17
I'd like to thank Chris for his amazing work in audio and his xHE implementation

Me too and my constant search for flaws is nothing more than a desire to convert all my recordings with Exhale.

Chris did a great job of optimizing the male voices. This time I will write it in a synthetic way, an additional calibration in SBR mode would be needed when there is a male speech sampled at 32kHz in input.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-03-14 22:27:44
All the searching, testing, and reporting is much appreciated. Thanks a lot! :)

Yes, when encoding speech (or even music) input sampled at 32 kHz with one of the SBR presets, upsampling the input to 44.1 or 48 kHz before encoding may lead to better quality. Basically, the dual-rate SBR technology was designed to work best at 44.1 or 48 kHz input sampling rate.

...my constant search for flaws is nothing more than a desire to convert all my recordings with Exhale.
The upcoming release 1.1.4 should be a good version to do that. I'll be doing the same with my FLAC collection.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: wyup on 2021-03-14 23:00:42
exhale v1.1.4-5bfcbaca {BETA1}
Built on March 13, 2021, GCC 10.2.0


Also big thanks to @NetRanger for gracefully providing and updating the binaries ;-)
Title: Re: exhale - Open Source USAC encoder
Post by: scharfis_brain on 2021-03-20 18:13:00
Indeed. scharfis_brain, is Dolby Surround encoded stereo audio still really that commonplace? The last audio CD in my collection on which I saw that (German band Schiller) is 20 years old.

Dolby Surround encoding is almost never mentioned on 2.0 content. It is simply "built-in".
However nearly every content I listen to on my surround set has strong action in the rear channels.
This is only possbile, when there is a huge amount of 180° phase shifted audio.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-03-20 23:19:43
Good to know, thanks for the clarification. Meanwhile, I finished a first exhale 1.1.4 release candidate with slightly modified framing (this (https://gitlab.com/ecodis/exhale/-/commit/ab91fd8f) commit). Please report any unexpected playback issues not occurring with a previous release of exhale. Thanks.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-03-21 01:47:33
Test versions: exhale@ab91fd8f-linux-armv7l.bz2 (http://www.paladino.ct.it/exhale@ab91fd8f/exhale@ab91fd8f-linux-armv7l.bz2) - exhale@ab91fd8f-macOS-arm64.zip (http://exhale@ab91fd8f-macOS-arm64.zip)

In my opinion I have some problems: I still perceive more defects in the male speech than I can find in the male singing, but now they are clearly annoying only at the lower bitrates.

I don't like to see a voice-only setting in a generalist encoder but maybe that's the only way to improve to 24kbps (like the --speech option in Opus). In this way you can eliminate anything above 16kHz (other ancoders already do this) and use the saved bits to improve the low frequencies typical of male vocal cords.

I leave you below the link to an uncompressed file that lasts 1 min. which I used as a test, this time a song recorded with an AKG P200 microphone.
AKG P200 - Back home.wav (https://bit.ly/3eZ5OrA)

Data format
2 ch,  44100 Hz, 'lpcm' (0x00000009) 32-bit little-endian float - no channel layout
estimated duration: 60.000000 sec
audio bytes: 21168000
audio packets: 2646000
bit rate: 2822400 bits per second
packet size upper bound: 8
maximum packet size: 8
audio data file offset: 4096
optimized
source bit depth: F32

Loudness info - additional loudness parameters
aa noise floor master: "-78.71 -78.71"
aa headroom master: "0.618395 0.614481"

Main loudness parameters
aa ebu max momentary loudness: -14.2571
aa ebu top of loudness range: -15.85
aa itu sample peak: -4.47742
aa itu true peak: -4.4707
aa ebu max short-term loudness   : -15.3241
aa ebu loudness range: 14.3
aa itu loudness: -18.9907

Dialogue anchor parameters
aa itu loudness: -1

Sound check info
sc ave perceived power coeff: "310 318"
sc max perceived power coeff: "3214 3069"
sc peak amplitude msec: "36989 46510"
sc max perceived power msec: "36989 36989"
sc peak amplitude: "19569 19265"

bit depth pcm master: 32

sound check volume normalization gain: 2.99 dB.

The results obtained with exhale@5bfcbaca mode 1 (http://www.paladino.ct.it/exhale@ab91fd8f/20210321-1.m4a) | 2 (http://www.paladino.ct.it/exhale@ab91fd8f/20210321-2.m4a) | 3 (http://www.paladino.ct.it/exhale@ab91fd8f/20210321-3.m4a) | 4 (http://www.paladino.ct.it/exhale@ab91fd8f/20210321-4.m4a) | 5 (http://www.paladino.ct.it/exhale@ab91fd8f/20210321-5.m4a) | 6 (http://www.paladino.ct.it/exhale@ab91fd8f/20210321-6.m4a) | 7 (http://www.paladino.ct.it/exhale@ab91fd8f/20210321-7.m4a) | 8 (http://www.paladino.ct.it/exhale@ab91fd8f/20210321-8.m4a) | 9 (http://www.paladino.ct.it/exhale@ab91fd8f/20210321-9.m4a) | a (http://www.paladino.ct.it/exhale@ab91fd8f/20210321-a.m4a) | b (http://www.paladino.ct.it/exhale@ab91fd8f/20210321-b.m4a) | c (http://www.paladino.ct.it/exhale@ab91fd8f/20210321-c.m4a) | d (http://www.paladino.ct.it/exhale@ab91fd8f/20210321-d.m4a) | e (http://www.paladino.ct.it/exhale@ab91fd8f/20210321-e.m4a) | f (http://www.paladino.ct.it/exhale@ab91fd8f/20210321-f.m4a) | g (http://www.paladino.ct.it/exhale@ab91fd8f/20210321-g.m4a) .
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-03-21 11:04:58
Sorry, celona (and all others with the same interest), if I disappoint you by saying this, but my previous comment about the limitations of exhale's USAC implementation simply means: If you want good-quality speech encodings at 24 kbps mono or lower, then exhale is not for you. I guess you need to look out for commercial xHE-AAC encoders supporting ACELP/TCX coding.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2021-03-21 11:57:06
Intel compiles of: exhale-v1.1.4-RC1-ab91fd8f

www.rarewares.org/files/aac/exhale-v1.1.4-RC1-ab91fd8f_x64.zip (http://www.rarewares.org/files/aac/exhale-v1.1.4-RC1-ab91fd8f_x64.zip)

www.rarewares.org/files/aac/exhale-v1.1.4-RC1-ab91fd8f_x86.zip (http://www.rarewares.org/files/aac/exhale-v1.1.4-RC1-ab91fd8f_x86.zip)

:)
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2021-03-21 17:48:00
exhale v1.1.4-ab91fd8f {RC1}
Built on March 21, 2021, GCC 10.2.0
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-03-23 06:15:47
Sorry, celona (and all others with the same interest), if I disappoint you by saying this, but my previous comment about the limitations of exhale's USAC implementation simply means: If you want good-quality speech encodings at 24 kbps mono or lower, then exhale is not for you. I guess you need to look out for commercial xHE-AAC encoders supporting ACELP/TCX coding.

Chris

The fact that in 2020 I wrote that it was the right time to implement ACELP should not be used today to think that I am finding flaws in Exhale to get it. I wrote it because a small developer has to move years in advance, he can't wait for patents to expire to do so. For those who aspire to use xHE-AAC it is a bit early, but it is time to start planning a future encoder change.

I've listened to a lot of compressed files and got the idea that I need a minimum bitrate of 37kbps for 44.1kHz sampled monophonic content and obviously my tests say that not only is ACELP/TCX missing, the fact that monophonic content is worse than the stereophonic ones it's like if the new PS was not used, which notoriously starts from the same downmixing in both cases. Adding background music to the speech forces the encoder to use a higher bitrate and defects tend to disappear. When I wrote that the bitrate had increased I was happy because only by allowing 5kbps more to 32kbps (exhale 1) you can get the best compromise.

For us who are not Netflix or broadcaster, until now raising the bitrate is economically convenient compared to buying a commercial encoder.
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-03-23 07:12:21
Important update for foo_pd_aac: Basically, due to a stupid way I was handling the first packet analysis handler for the packet decoder, was causing the new Immediate Playout Frame gapless encoding preroll method to glitch out.

Basically, the libfdkaac doesn't provide a way to completely reset a decoder without deleting and recreating it. Resetting it just flushes it. Flushing causes IPF frames to think there was a stream error in need of recovery, and it will crossfade the start of the actual frame with the last frame that got decoded before the flush, which was the same exact frame. So the start of the frame gets crossfaded with part of the end of itself. Oopsies.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-03-23 10:37:57
Awesome, thanks very much for this fix, works great! As always, your prompt reaction here is much appreciated.

For those not following all of what happens on this thread: kode54 is talking about https://www.foobar2000.org/components/view/foo_pd_aac

Thanks for the info, celona. I'm happy to hear that just increasing the bit-rate (CVBR preset) works for you. I just committed an exhale 1.1.4 RC2. Please update to version 1.15 of the FDK-AAC packet decoder for foobar2000 before testing.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2021-03-23 12:59:35
exhale v1.1.4-ad888151 {RC2}
Built on March 23, 2021, GCC 10.2.0
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2021-03-23 14:39:13
Intel compiles of exhale-V1.1.4-RC2-ad888151

www.rarewares.org/files/aac/exhale-V1.1.4-RC2-ad888151_x64.zip (http://www.rarewares.org/files/aac/exhale-V1.1.4-RC2-ad888151_x64.zip)

www.rarewares.org/files/aac/exhale-V1.1.4-RC2-ad888151_x86.zip (http://www.rarewares.org/files/aac/exhale-V1.1.4-RC2-ad888151_x86.zip)

Edit: The links are now correct. They were delivering the RC1 version. Thanks to capma for pointing this out.
Title: Re: exhale - Open Source USAC encoder
Post by: AiZ on 2021-03-23 23:28:41
Hello,

I haven't noticed that before and can't remember if it's by design : why an exhale encoded track can have an audible difference in loudness, compared to other formats?

I have compiled the latest git update, updated foo_pd_aac, encoded some of my regular test tracks and... Remember, I'm not good at all in ABX tests but something was bothering me on one track. Using Replaygain Scan in foobar, it shows that exhale encoding has a track gain of -9.72dB, while mp3/aac/opus/ogg average at -11dB (Track peak is 0.89 vs avg. 1.32). And with foobar ABX tools, switching between tracks makes exhale's one less... Punchy?

I've browsed (too) quickly the thread, can it be related to fdk-aac decoding? exhale file loudness computation? Or both?

Sorry if you have already explained this.

    AiZ
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-03-23 23:41:57
The USAC decoder has a dynamics compressor built-in, and will compress the audio to within 0.01 dB of maximum loudness on playback. Chris asked me to leave this enabled, or at least retune the default to that 0.01 dB threshold rather than the 0.1 dB it was originally, rather than outright disable it. Note, this is mostly a peak limiter, and it's sort of ideal to enable it for USAC anyway, since FDK doesn't support floating point decoding, or decoding with a fixed point that would preserve ±1.0 exceeding peaks.

USAC files will always have a compressor in the decoder, unless a particular implementation disables it.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-03-24 00:09:22
can't remember if it's by design : why an exhale encoded track can have an audible difference in loudness, compared to other formats?
That's certainly not intended, and I didn't notice this on any of the music in my collection. What kode54 mentioned doesn't produce such audible effects (especially not with the 0.01 dB threshold). Can you reproduce this behavior with a short input file that you can share? Otherwise, please send me a PM.

Or maybe it's related to ReplayGain? In principle, you shouldn't need that anyway; exhale calculates and stores its own loudness measurement (ITU BS.1770) inside the .m4a files. I don't think foobar2000 actually makes use of that information, though, or if it even applies ReplayGain to USAC files at all.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: AiZ on 2021-03-24 07:19:03
Hello,

The USAC decoder has a dynamics compressor built-in, and will compress the audio to within 0.01 dB of maximum loudness on playback. Chris asked me to leave this enabled, or at least retune the default to that 0.01 dB threshold rather than the 0.1 dB it was originally, rather than outright disable it. Note, this is mostly a peak limiter, and it's sort of ideal to enable it for USAC anyway, since FDK doesn't support floating point decoding, or decoding with a fixed point that would preserve ±1.0 exceeding peaks.

USAC files will always have a compressor in the decoder, unless a particular implementation disables it.

"Peak limiter" seems to fit right here, for what I understand in audio (well, I must say, not that much...).

That's certainly not intended, and I didn't notice this on any of the music in my collection. What kode54 mentioned doesn't produce such audible effects (especially not with the 0.01 dB threshold). Can you reproduce this behavior with a short input file that you can share? Otherwise, please send me a PM.

Here we go with a 30 seconds clip.

Thanks,

    AiZ
Title: Re: exhale - Open Source USAC encoder
Post by: Brazil2 on 2021-03-24 10:13:49
Here we go with a 30 seconds clip.
vite.flac
Best clipping sample ever!  (https://www.cosgan.de/images/midi/froehlich/a1161.gif)
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-03-24 10:54:11
Indeed. Thanks! So, here's what I get: on the command-line, exhale reports a peak of -0.00 dbFS, which is the same as foobar2000's ReplayGain scanner reports on AiZ's FLAC file. But on the .m4a file of that vite.flac, foobar reports a peak of 0.891 = -1.0 dBFS, so when scanning for ReplayGain, the FDK-AAC packet decoder apparently (kode54, please confirm) seems to apply the USAC decoder limiter not at -0.01 dBFS as during playback, but at -1 dBFS. Which makes ReplayGain think the exhale encoding of your sample FLAC is quieter than it actually is.

If I had a free wish left, I'd love to eventually see foobar2000's ReplayGain scanner just taking the existing "program loudness" values stored inside the xHE-AAC files when deriving the "track gain" values. This way, the original input files' loudness information inside the xHE-AAC files is preserved when applying ReplayGain. Of course I can assist in the parsing of this information. Also (oops, another wish), when applying ReplayGain during playback, the gain should be applied before USAC's decoder limiter is executed, but I don't know if that's possible with an "external" packet decoder.

So not an exhale encoder issue, it seems.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-03-24 13:19:04
Test versions: exhale_ad888151-Linux-armv7l.bz2 (http://celona.altervista.org/exhale/ad888151/exhale_ad888151-Linux-armv7l.bz2) - exhale_ad888151-macOS-amr64.zip (http://celona.altervista.org/exhale/ad888151/exhale_ad888151-macOS-amr64.zip)

From macOS Terminal
Code: [Select]
exhale 1 vite.wav vite.m4a

Code: [Select]
  ---------------------------------------------------------------------
 | exhale - ecodis extended high-efficiency and low-complexity encoder |
 |                                                                     |
 | version 1.1.4 (ARM, built on Mar 24 2021) - written by C.R.Helmrich |
  ---------------------------------------------------------------------

 WARNING: The input sampling rate should be 32 kHz or less for preset mode 1!

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

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

 Input statistics:  File loudness -7.15 LUFS, sample peak level -0.00 dBFS

Before compression
Code: [Select]
File type ID:   WAVE
Num Tracks:     1
----
Data format:     2 ch,  44100 Hz, 'lpcm' (0x0000000C) 16-bit little-endian signed integer
                no channel layout.
estimated duration: 29.998571 sec
audio bytes: 5291748
audio packets: 1322937
bit rate: 1411200 bits per second
packet size upper bound: 4
maximum packet size: 4
audio data file offset: 4096
optimized
source bit depth: I16
Loudness Info:
    additional loudness parameters   :
        aa noise floor master            : "-75.01 -75.66"
        aa headroom master               : "0.001957 0.000000"
        aa source bandwidth master       : "17140 20887"

    main loudness parameters         :
        aa ebu max momentary loudness    : -5.09673
        aa ebu top of loudness range     : -6.65
        aa itu sample peak               : 0
        aa itu true peak                 : 1.67381
        aa ebu max short-term loudness   : -6.45551
        aa ebu loudness range            : 0.899998
        aa itu loudness                  : -7.11756

    dialogue anchor parameters       :
        aa speech activity percentage    : 8.01282
        aa ebu loudness range            : 5.1
        aa itu loudness                  : -13.5581

    sound check info                 :
        sc ave perceived power coeff     : "7963 6942"
        sc max perceived power coeff     : "58005 62592"
        sc peak amplitude msec           : "46 395"
        sc max perceived power msec      : "5782 5782"
        sc peak amplitude                : "32767 32768"

    bit depth pcm master             : 16

sound check volume normalization gain: -8.88 dB

After compression
Code: [Select]
File type ID:   WAVE
Num Tracks:     1
----
Data format:     2 ch,  44100 Hz, 'lpcm' (0x0000000C) 16-bit little-endian signed integer
                no channel layout.
estimated duration: 29.998571 sec
audio bytes: 5291748
audio packets: 1322937
bit rate: 1411200 bits per second
packet size upper bound: 4
maximum packet size: 4
audio data file offset: 4096
optimized
source bit depth: I16
Loudness Info:
    additional loudness parameters   :
        aa noise floor master            : "-98.68 -99.41"
        aa headroom master               : "0.000000 0.000000"
        aa source bandwidth master       : "14643 14643"

    main loudness parameters         :
        aa ebu max momentary loudness    : -5.4357
        aa ebu top of loudness range     : -6.85
        aa itu sample peak               : 0
        aa itu true peak                 : 1.98502
        aa ebu max short-term loudness   : -6.67604
        aa ebu loudness range            : 0.900002
        aa itu loudness                  : -7.31181

    dialogue anchor parameters       :
        aa speech activity percentage    : 8.01282
        aa ebu loudness range            : 6.3
        aa itu loudness                  : -13.366

    sound check info                 :
        sc ave perceived power coeff     : "7416 6558"
        sc max perceived power coeff     : "51679 49534"
        sc peak amplitude msec           : "70 70"
        sc max perceived power msec      : "5782 5782"
        sc peak amplitude                : "32768 32768"


sound check volume normalization gain: -8.69 dB

At first listening I did not notice any differences in the audio level, which however are found in the metadata of the wav files.

The two details: before.txt (http://celona.altervista.org/exhale/ad888151/before.txt) - after.txt (http://celona.altervista.org/exhale/ad888151/after.txt).
Title: Re: exhale - Open Source USAC encoder
Post by: Kraeved on 2021-03-24 22:02:35
Intel compiles of: exhale-v1.1.4-RC1-ab91fd8f
www.rarewares.org/files/aac/exhale-v1.1.4-RC1-ab91fd8f_x64.zip (http://www.rarewares.org/files/aac/exhale-v1.1.4-RC1-ab91fd8f_x64.zip)

I gave it a shot on Windows 7. Houston, we have a problem.

Spoiler (click to show/hide)

Bug is caused by incorrect path interpretation if Exhale is stored in some folder within PATH environment variable, not in the WAV folder. Not to mention it is rather odd to output non-Latin folder names as question marks in the 21st (Unicode) century. When I placed Exhale right next to input file, the job was finished.

Spoiler (click to show/hide)

Also I wonder what is chr reported as Title
Title: Re: exhale - Open Source USAC encoder
Post by: AiZ on 2021-03-24 22:27:50
Hello,

Bug. Exhale is stored in some folder within PATH environment variable, not in the WAV folder, but tries to find an input file next to itself.

Nope. See Usage here (https://gitlab.com/ecodis/exhale#standalone-command-line).

Prefix input and output file with .\ in your command:
Quote
$ exhale g ".\George Michael - White light.wav" .\out.m4a

    AiZ
Title: Re: exhale - Open Source USAC encoder
Post by: Kraeved on 2021-03-24 23:13:43
AiZ, it goes against decades-long practice (check any popular CLI app), so it’s either (mildly put) bug or (bluntly put) developer’s negligence served with a dodgy disclaimer (like, you know, collateral damage is a beclouding term to report of murdered non-combatants).

Now, back to music. Let’s enjoy a 30 seconds clip of Boat to Havana by Terence Blanchard from Original Sin OST.
I attached FLAC, Exhale’s output with g switch, and FDK (https://forum.doom9.org/showthread.php?t=171561&page=2)’s HE-AAC v2 (SBR+PS) output with -p 29 -m 5 switches (or -vbr 5 in terms of FFMPEG (https://github.com/AnimMouse/ffmpeg-stable-autobuild)’s libfdk_aac).
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-03-24 23:58:36
I don't get it. I put exhale.exe (my own VS2012 compile) into some directory listed in Windows 7's Path environment variable, opened a command prompt, went to some other directory with WAV files and could call "exhale g in.wav out.m4a" just fine. Also, someone reported here previously that Unicode works as well.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: IgorC on 2021-03-25 00:03:43
I attached FLAC, Exhale’s output with g switch, and FDK (https://forum.doom9.org/showthread.php?t=171561&page=2)’s HE-AAC v2 (SBR+PS) output with -p 29 -m 5 switches (or -vbr 5 in terms of FFMPEG (https://github.com/AnimMouse/ffmpeg-stable-autobuild)’s libfdk_aac).
You do realize that those settings don't make any sense and actually produce inferior quality, right?
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-03-25 01:48:44
Oops, I somehow lost that change to the USAC PCM peak limiter to -0.1 dBFS instead of -1.0 dBFS. It is now committed to my fork of libfdk-aac.
Title: Re: exhale - Open Source USAC encoder
Post by: Kraeved on 2021-03-25 11:53:02
I attached FLAC, Exhale’s output with g switch, and FDK (https://forum.doom9.org/showthread.php?t=171561&page=2)’s HE-AAC v2 (SBR+PS) output with -p 29 -m 5 switches (or -vbr 5 in terms of FFMPEG (https://github.com/AnimMouse/ffmpeg-stable-autobuild)’s libfdk_aac).
You do realize that those settings don't make any sense and actually produce inferior quality, right?

Broadcasters use similar settings (http://fmstream.org/index.php) and ordinary listeners are curious about xHE-AAC vs HE-AAC v2 (https://hydrogenaud.io/index.php?topic=111045.0) comparison, so it makes sense to me.
They damage in the least possible way, keeping in mind the technologies involved (SBR vs SBR+PS), i.e. a & -m 1 produce worse results.
That said, I am well aware that you have a peculiar point of view on many audio-related issues, so hurry up to enlighten preach share.
Title: Re: exhale - Open Source USAC encoder
Post by: Kamedo2 on 2021-03-25 13:54:18
A slightly killer sample on the exhale-v1.1.4-RC1-ab91fd8f_x64 a, b, c, d, e, and f.
Sandpaper-like artifacts on the Glockenspiel C9 8.32kHz and G9 12.54kHz note is audible, only when the SBR is enabled.
I don't believe this is a serious problem, and it may be unavoidable, but I will report it anyway.

From ICD-66013 COLLECTIVE Track04 Do you know the magic? / Kaori Utatsuki 00:00-00:11
Title: Re: exhale - Open Source USAC encoder
Post by: IgorC on 2021-03-25 15:04:41
Broadcasters use similar settings (http://fmstream.org/index.php) and ordinary listeners are curious about xHE-AAC vs HE-AAC v2 (https://hydrogenaud.io/index.php?topic=111045.0) comparison, so it makes sense to me.
They damage in the least possible way, keeping in mind the technologies involved (SBR vs SBR+PS), i.e. a & -m 1 produce worse results.
That said, I am well aware that you have a peculiar point of view on many audio-related issues, so hurry up to enlighten preach share.
Simply and shortly. Nothing peculiar and it's verified/tested/well known here that SBR is useful only up to ~72-75 kbps (ok, max 80 kbps if we speaking of CBR)... even if we talk about xHE-AAC.  As of PS, it's only useful up to ~36 (max 40 kbps for CBR).

Any higher than those rates and SBR/PS are already harmful and it's recommended to disable them.
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-03-25 18:15:51
...it's only useful up to ~36 (max 40 kbps for CBR).
Any higher than those rates and SBR/PS are already harmful and it's recommended to disable them.

I believe you are right and broadcasters have new rules this year (see https://www.etsi.org/deliver/etsi_es/201900_201999/201980/04.02.01_60/es_201980v040201p.pdf (https://www.etsi.org/deliver/etsi_es/201900_201999/201980/04.02.01_60/es_201980v040201p.pdf))

I mentioned the absence of PS for another reason: recording the speech in stereo I do not get the artifacts present in mono, obviously after compression. This is because Exhale almost always needs a higher bitrate than imagined for his settings. It is not a problem to drive the developer crazy but it must be addressed to help the user.

It should also be thought of as making sense of an encoder that is among the paid solutions, which use half the data at the same yield, and free solutions such as Opus, which offers higher quality on speech.

For me the only way is to offer advantages, free for those who cannot afford paid versions, no need for transcoding and the best compatibility in every area of ​​use of the same file (still not obtainable with Opus) at the right bitrate.

So we might as well be clear, you need between 37 and 48kbps for a monophonic signal, regardless of the use of SBR, the yield will be bearable above 256kB per minute, better above 300kB per minute. And on this I agree with the author, companies like Vodafone are shutting down the 3G network everywhere, leaving 2G for phone calls to better satisfy the demand for data from users with LTE connections. Those who have imagined the need to hear 2G audio in the most disadvantaged areas have not considered that people do not want to shut themselves up in a "ghetto" and will want to hear audio from more advanced regions. Therefore it does not matter to chase 16kbps, which in any case flatten the quality of the content and with the cost of disk space and bandwidth (the example of the Italian speaker must be evaluated taking into account that in that country 100GB per month cost less than € 7 and when the user finishes them he can get another 100 at the same price or opt for a flat rate solution for less than € 21 per month on the cellular network as on fiber) we can also live with double bitrates compared to the 24kbps imagined as a limit for Exhale.

Today there is a demand for higher quality in speech, the need to listen to conferences, podcasts, lectures or in any case recordings for hours has made people more aware of how tiring it is to listen to overly compressed signals for a long time, especially with HE- AAC. This is the main lever to switch to xHE-AAC, especially considering that the metallization introduced by HE-AAC with SBR, combined with its uselessness at higher bitrates, suggests not using solutions that if listened to for a long time in headphones can lead to problems hearing. And if you think that there are lossless formats for music, it is hybrid contents that need this encoder to contain the space necessary to store them or the bandwidth to transmit them, HE-AAC is not the alternative, it will be the victim of successor xHE-AAC.

It could be useful an automatic setting that intervenes in place of the error message and that in the absence of parameters switches to Exhale 0 for sampling frequencies up to 22.05kHz, Exhale 1 for 24kHz, Exhale 2 for 32kHz, Exhale 3 for 44, 1kHz and 48kHz (at 48kbps). For years, broadcasters have been suggested to use only 48kHz, which creates the space for which SBR makes sense.

Making a good impression on new users is important and in my opinion the Exhale target can only be the users more interested in the quality than in the bitrate obtained and to return to the Italian speaker so difficult to compress, one who was professionally born with FM radio, as a professional (if he uses a Neumann microphone he will not make excessive financial problems) he will want to create a site with a portfolio section in which to collect his works, which he already keeps in an ISO BFF container, which he distributes to everyone in this way because his time is money, and maybe he will want to use the HTML5 <audio> tag, without bothering to reconvert to multiple formats or to keep multiple formats because if he uses Opus he will have to incapusulate it in Ogg (ignoring the different extensions needed by old versions of Android) and in CAF because if it takes other paths there will always be someone who doesn't work. Furthermore, if he has to keep two 24kbps Opus files, it will be better for him to have an xHE-AAC file compressed with Exhale that gives him a better performance for the same disk space and allows him to use only that. Radio broadcasters offering podcasts of their programs have the same interest, having only one container and one content for every need.

This is the advantage that Exhale will have on the day Microsoft follows up on the commercial agreement of July 1, 2020, only BSD and Linux users will have any problems and they are determined and know how to arrange cooperatively (all mobile and tablet operating systems have agreements for the use of the libfdk-aac decoder).
Why is it important to use the right bitrate? In Europe we have an epic failure called DAB, which even in its most recent version called DAB + has not made a splash among users despite a more than ten-year presence.

In my country, when a person turns on the radio in their car, they switch to FM because they can't stand the flaws of an overly compressed digital alternative. I believe my country also drives intolerance to distance learning and audio quality with Team, Skype (which just got better) and Zoom.

The rest of the users in the part of the world as seen by my eyes will never want to mess with how to compress a recording and will be satisfied with what the manufacturer of their operating system has chosen, they will even feel annoyed having to learn something new if the quality is adequate.
Title: Re: exhale - Open Source USAC encoder
Post by: sveakul on 2021-03-25 23:13:59
Oops, I somehow lost that change to the USAC PCM peak limiter to -0.1 dBFS instead of -1.0 dBFS. It is now committed to my fork of libfdk-aac.
Kode54, shouldn't that be -.01 dBFS instead of -0.1 dBFS?  I'm getting a bit lost but I ask this based on your previous comment  below:

"Quote from: kode54 on 2021-03-23 23:41:57
    The USAC decoder has a dynamics compressor built-in, and will compress the audio to within 0.01 dB of maximum loudness on playback. Chris asked me to leave this enabled, or at least retune the default to that 0.01 dB threshold rather than the 0.1 dB it was originally."
Title: Re: exhale - Open Source USAC encoder
Post by: soundping on 2021-03-26 00:32:34
NIN sounds fine.
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-03-26 00:35:26
Kode54, shouldn't that be -.01 dBFS instead of -0.1 dBFS?  I'm getting a bit lost but I ask this based on your previous comment  below:

"Quote from: kode54 on 2021-03-23 23:41:57
    The USAC decoder has a dynamics compressor built-in, and will compress the audio to within 0.01 dB of maximum loudness on playback. Chris asked me to leave this enabled, or at least retune the default to that 0.01 dB threshold rather than the 0.1 dB it was originally."
Uh, yeah, it is that, not 0.1. And it's actually the linear PCM peak level float constant that Chris gave me, which I inserted into my copy of libfdk-aac:

https://git.lopez-snowhill.net/chris/fdk-aac/-/commit/fcc2603828cac51b6ee5f3301b5b071c2e3d92a0
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-03-26 01:16:56
Don't worry, people, the difference between -0.1 and -0.01 dBFS won't be audible at all. Just leave it as it is (0.98855 is -0.1 dB).

As of PS, it's only useful up to ~36 (max 40 kbps for CBR).
Indeed, the DRM standard linked to by celona (thanks!) recommends PS only in the range 18 - 26 kbit/s (see sec. 5.4.3), and I second that recommendation. The FDK-AAC encoding of "Boat to Havana" above averages at 61 kbit/s, so should definitely not be using PS. And the bitrate-comparable exhale preset is "c" here, not "g", by the way.

A slightly killer sample ... don't believe this is a serious problem, and it may be unavoidable, but I will report it anyway.
Yeah, that issue is related to exhale's greatly simplistic SBR encoder and cannot be avoided really.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: jaybeee on 2021-03-26 09:30:53
@C.R.Helmrich I have a small suggestion to improve the clarity of Exhale usage on the Exhale github page (https://gitlab.com/ecodis/exhale) / readme.md:

Provide more detail on the best to worst parameter settings. So, at the moment it just says:

0...9 when SBR is disabled, or a...g when SBR is enabled

It doesn't say whether 0 is best or 9 is best, or indeed if a is better than g, and even if 0...9 is better than a...g.

Also, target bitrates would be helpful for users too like LAME (https://wiki.hydrogenaud.io/index.php?title=Lame#Recommended_settings_details).
 :)
Title: Re: exhale - Open Source USAC encoder
Post by: Kraeved on 2021-03-26 11:41:13
I don't get it. I put exhale.exe (my own VS2012 compile) into some directory listed in Windows 7's Path environment variable, opened a command prompt, went to some other directory with WAV files and could call "exhale g in.wav out.m4a" just fine. Also, someone reported here previously that Unicode works as well.

I look outside my window and see no deliberate violence towards people of color, neither do my peers. Does it mean there is no such issue and BLM reports from abroad should be dismissed? Or, it is just me, who is lucky enough to live in the place with no unresolved colonial/slavery past? Still not get it? A local citizen might say “somewhere else, does not matter (yet)”, but a developer, whose solutions assume global relevance (xHE-AAC encoder for that matter), is expected to be more curios about troubleshooting. For example, visit issue trackers of Yann Collet (LZ4, Zstandard, xxHash) and John MacFarlane (Pandoc) to get inspired.

Now, back to Exhale. Path bug. Put exhale.exe in c:\Apps, go to c:\Music, execute c:\Apps\exhale.exe g in.wav out.m4a and there will be ERROR while trying to open input file c:\Apps\in.wav! Does it already exist? Other CLI apps (e.g. xxhsum) throw no errors in this case and process paths correctly. Unicode bug. Rename c:\Apps to c:\Программы and try again, there will be the same error message with a new part c:\?????????\in.wav. Changing codepage with chcp does not help.
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2021-03-26 14:22:01
The above problem is manifested when trying to call exhale from a directory which is not listed in the Path environment variable. I've just tested it myself with the same result. Calling lame in exactly the same way works without issue.
Title: Re: exhale - Open Source USAC encoder
Post by: Kraeved on 2021-03-26 16:11:40
john33
Actually the issue can be reproduced even when exhale.exe is in PATH (that’s how I originally caught it) — you just have to execute the app not in a bare cmd.exe window, but in known file managers with a command line wrapper (Far (https://farmanager.com/) and Total Commander (https://www.ghisler.com/) to name a few). Lame works there as well, Exhale does not.
Title: Re: exhale - Open Source USAC encoder
Post by: [JAZ] on 2021-03-26 17:43:43
@Kraeved I'm not here to moderate this post, but you should really change the way you are posting.
I will assume that you had a misunderstanding (either caused by non-native language or by using impersonal communication means like a board) and got Helmrich reply wrong.

You reported a problem
He reported that he could not reproduce it
Your expected response is: See, I did these exact steps to reproduce them.
Instead you blamed him for not being able to reproduce your problem plus some racial bla bla..
Title: Re: exhale - Open Source USAC encoder
Post by: synclagz on 2021-03-26 17:58:29
I just discovered that Cx File Explorer for Android plays Exhale encoded audio (among other stuff :))
Just wanted to share this. I hope it will be helpful. ;-)
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-03-26 18:16:00
I probably made a mistake by writing a message that was too long to talk about the social context rather than the software, and this took everyone's time away. Not even I have tried to reproduce the defect reported by Kraeved, I preferred to postpone it to the weekend because I work with macOS, Linux or in any case with compatible Posix command lines and I need more time to not sacrifice my family between work and this tiring passion .

We try to understand each other, the method is right, Kraeved gave us the indications to reproduce, it takes longer to get feedback and I probably stretched them unnecessarily and gave a bad example.
Title: Re: exhale - Open Source USAC encoder
Post by: itisljar on 2021-03-26 18:24:49
E:\GLAZBA-WORK>chcp
Active code page: 852

exhale works fine if it is in folder with other cmd tools I use, and folder is added to PATH variable. When executing exhale from another folder that isn't in path, it completely ignores folder I am in and searches for input file in folder where exe file is. And it should first search for input file in folder I am currently.

Code: [Select]
E:\GLAZBA-WORK>e:\work\exhale 4 music.wav music.m4a
  ---------------------------------------------------------------------
 | exhale - ecodis extended high-efficiency and low-complexity encoder |
 |                                                                     |
 | version 1.1.3 (x64, built on Mar  1 2021) - written by C.R.Helmrich |
  ---------------------------------------------------------------------
 ERROR while trying to open input file e:\work\music.wav! Does it already exist?

Lame works as expected:

Code: [Select]
E:\GLAZBA-WORK>e:\work\lame music.wav music.mp3
LAME 3.100 64bits (http://lame.sf.net)
CPU features: SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding music.wav to music.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III (11x) 128 kbps qval=3
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
  9266/9266  (100%)|    0:03/    0:03|    0:03/    0:03|   69.375x|    0:00
-------------------------------------------------------------------------------
   kbps        LR    MS  %     long switch short %
  128.0        6.3  93.7        97.4   1.4   1.1
Writing LAME Tag...done
ReplayGain: -7.6dB

Monkey's Audio also works as expected:

Code: [Select]
E:\GLAZBA-WORK>e:\work\mac music.wav music.ape -c1000
--- Monkey's Audio Console Front End (v 4.12) (c) Matthew T. Ashland ---
Compressing (fast)...
Progress: 100.0% (0.0 seconds remaining, 0.8 seconds total)
Success...

So, as I tested, and from my lifelong experience with command line tools, exhale doesn't work "by the book". It should look in current, working directory for files first, then in it's own directory, and only then throw an error. It shouldn't skip lookup. And I don't think it has problem with unicode, I think it has problem with where it searches files first.
Title: Re: exhale - Open Source USAC encoder
Post by: Kraeved on 2021-03-26 18:57:27
@Kraeved I'm not here to moderate this post, but you should really change the way you are posting.
I will assume that you had a misunderstanding (either caused by non-native language or by using impersonal communication means like a board) and got Helmrich reply wrong. … Instead you blamed him for not being able to reproduce your problem plus some racial bla bla..

The way I write changes depending on the behavior of the other party. When the other party produces spaghetti code, then does not try to debug as it works on his end, then gives a formal reply on the app’s issue tracker with no intent to help such as “if exhale.exe -V displays Unicode flag, than Unicode is there, dixi”, then the communication goes downhill, obviously. So there is no language misunderstanding here. Make no mistake: doing something for free in your spare time and sharing it is great, but does not grant access to the hall of fame by itself. When you share something, expect to process various feedback, not exclusively positive, because there is a certain level of expectations set by the achievements of ancestors. The feedback includes bashing, because there are more and more quitters who fuel expectations but fail to deliver — let’s hope Christopher Helmrich does not belong to that tribe and Exhale’s bugs are caused by COVID-19 ambience, not by a lack of dedication. That said, I am still polite and follow the rules of beloved Hydrogenaudio, but no longer try to cajole that particular developer. Instead, I promoted examples of decent development and provided more details about bugs. As for “racial bla bla”, it’s called reasoning by analogy, but oh well.

Now, back to Exhale. Its path bug happens in Powershell (5.0) as well.
Title: Re: exhale - Open Source USAC encoder
Post by: m14u on 2021-03-26 18:57:45
linux native exhale cli - work;
linux native exhale via deadbeef - not work;
wine win-exhale cli/ via eac - not work;
wine win-exhale via foobar - work.
it is about a unicode.
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-03-26 19:51:02
That is correct, at least for Windows. It needs to explicitly have a wmain function, or it needs to use something like FLAC does on Windows, which is hooking other functions to perform argument decoding in UTF-8, and decoding filenames in UTF-8, and printing output to the terminal in UTF-8 where necessary.
Title: Re: exhale - Open Source USAC encoder
Post by: Kraeved on 2021-03-26 23:34:02
Indeed, the DRM standard linked to by celona (thanks!) recommends PS only in the range 18 - 26 kbit/s (see sec. 5.4.3), and I second that recommendation. The FDK-AAC encoding of "Boat to Havana" above averages at 61 kbit/s, so should definitely not be using PS. And the bitrate-comparable exhale preset is "c" here, not "g", by the way.
Chris
…let’s hope Christopher Helmrich…
Oh, Chris ≠ Christopher here, it’s for Christian.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-03-27 01:22:10
OK, thanks to the others I understood the issue (path vs. Path/PATH) now. So I made a new commit which (1) mentions exhale's Wiki in the ReadMe (explaining the presets and listing the associated bit-rate ranges) and (2) changed exhale.exe to consider the current working directory instead of the called application directory. That issue was never a bug but intentional behavior, as the ReadMe or exhale itself when called without any arguments explains. That switch from application to current working directory isn't activated yet under Linux/Mac/ARM yet, though, since I can't test it. Any help here from other developers is appreciated (change line 64 in exhaleApp.cpp to "#define EA_USE_WORK_DIR 1 ..." and let me know if it works).

Regarding Unicode: exhale has all that, a wmain etc., under a macro EXHALE_APP_WCHAR in exhaleApp.cpp, line 35. Maybe that's not activated with some compilers?

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-03-27 01:41:08
Now it is no longer possible to compile from macOS.

Code: [Select]
/Users/christian/Downloads/exhale-master/src/app/../../src/app/exhaleApp.cpp:268:6: error: 
      macro expansion producing 'defined' has undefined behavior
      [-Werror,-Wexpansion-to-defined]
# if EA_USE_WORK_DIR
     ^
/Users/christian/Downloads/exhale-master/src/app/../../src/app/exhaleApp.cpp:64:29: note:
      expanded from macro 'EA_USE_WORK_DIR'
#define EA_USE_WORK_DIR    (defined (_WIN32) || defined (WIN32) || defin...
                            ^
/Users/christian/Downloads/exhale-master/src/app/../../src/app/exhaleApp.cpp:268:6: error:
      macro expansion producing 'defined' has undefined behavior
      [-Werror,-Wexpansion-to-defined]
/Users/christian/Downloads/exhale-master/src/app/../../src/app/exhaleApp.cpp:64:49: note:
      expanded from macro 'EA_USE_WORK_DIR'
#define EA_USE_WORK_DIR    (defined (_WIN32) || defined (WIN32) || defin...
                                                ^
/Users/christian/Downloads/exhale-master/src/app/../../src/app/exhaleApp.cpp:268:6: error:
      macro expansion producing 'defined' has undefined behavior
      [-Werror,-Wexpansion-to-defined]
/Users/christian/Downloads/exhale-master/src/app/../../src/app/exhaleApp.cpp:64:68: note:
      expanded from macro 'EA_USE_WORK_DIR'
#define EA_USE_WORK_DIR    (defined (_WIN32) || defined (WIN32) || defined (_WIN...
                                                                   ^
/Users/christian/Downloads/exhale-master/src/app/../../src/app/exhaleApp.cpp:268:6: error:
      macro expansion producing 'defined' has undefined behavior
      [-Werror,-Wexpansion-to-defined]
/Users/christian/Downloads/exhale-master/src/app/../../src/app/exhaleApp.cpp:64:88: note:
      expanded from macro 'EA_USE_WORK_DIR'
  ...(defined (_WIN32) || defined (WIN32) || defined (_WIN64) || defined (WIN...
                                                                 ^
/Users/christian/Downloads/exhale-master/src/app/../../src/app/exhaleApp.cpp:424:6: error:
      macro expansion producing 'defined' has undefined behavior
      [-Werror,-Wexpansion-to-defined]
#if !EA_USE_WORK_DIR
     ^
/Users/christian/Downloads/exhale-master/src/app/../../src/app/exhaleApp.cpp:64:29: note:
      expanded from macro 'EA_USE_WORK_DIR'
#define EA_USE_WORK_DIR    (defined (_WIN32) || defined (WIN32) || defin...
                            ^
/Users/christian/Downloads/exhale-master/src/app/../../src/app/exhaleApp.cpp:424:6: error:
      macro expansion producing 'defined' has undefined behavior
      [-Werror,-Wexpansion-to-defined]
/Users/christian/Downloads/exhale-master/src/app/../../src/app/exhaleApp.cpp:64:49: note:
      expanded from macro 'EA_USE_WORK_DIR'
#define EA_USE_WORK_DIR    (defined (_WIN32) || defined (WIN32) || defin...
                                                ^
/Users/christian/Downloads/exhale-master/src/app/../../src/app/exhaleApp.cpp:424:6: error:
      macro expansion producing 'defined' has undefined behavior
      [-Werror,-Wexpansion-to-defined]
/Users/christian/Downloads/exhale-master/src/app/../../src/app/exhaleApp.cpp:64:68: note:
      expanded from macro 'EA_USE_WORK_DIR'
#define EA_USE_WORK_DIR    (defined (_WIN32) || defined (WIN32) || defined (_WIN...
                                                                   ^
/Users/christian/Downloads/exhale-master/src/app/../../src/app/exhaleApp.cpp:424:6: error:
      macro expansion producing 'defined' has undefined behavior
      [-Werror,-Wexpansion-to-defined]
/Users/christian/Downloads/exhale-master/src/app/../../src/app/exhaleApp.cpp:64:88: note:
      expanded from macro 'EA_USE_WORK_DIR'
  ...(defined (_WIN32) || defined (WIN32) || defined (_WIN64) || defined (WIN...
                                                                 ^
/Users/christian/Downloads/exhale-master/src/app/../../src/app/exhaleApp.cpp:519:5: error:
      macro expansion producing 'defined' has undefined behavior
      [-Werror,-Wexpansion-to-defined]
#if EA_USE_WORK_DIR
    ^
/Users/christian/Downloads/exhale-master/src/app/../../src/app/exhaleApp.cpp:64:29: note:
      expanded from macro 'EA_USE_WORK_DIR'
#define EA_USE_WORK_DIR    (defined (_WIN32) || defined (WIN32) || defin...
                            ^
/Users/christian/Downloads/exhale-master/src/app/../../src/app/exhaleApp.cpp:519:5: error:
      macro expansion producing 'defined' has undefined behavior
      [-Werror,-Wexpansion-to-defined]
/Users/christian/Downloads/exhale-master/src/app/../../src/app/exhaleApp.cpp:64:49: note:
      expanded from macro 'EA_USE_WORK_DIR'
#define EA_USE_WORK_DIR    (defined (_WIN32) || defined (WIN32) || defin...
                                                ^
/Users/christian/Downloads/exhale-master/src/app/../../src/app/exhaleApp.cpp:519:5: error:
      macro expansion producing 'defined' has undefined behavior
      [-Werror,-Wexpansion-to-defined]
/Users/christian/Downloads/exhale-master/src/app/../../src/app/exhaleApp.cpp:64:68: note:
      expanded from macro 'EA_USE_WORK_DIR'
#define EA_USE_WORK_DIR    (defined (_WIN32) || defined (WIN32) || defined (_WIN...
                                                                   ^
/Users/christian/Downloads/exhale-master/src/app/../../src/app/exhaleApp.cpp:519:5: error:
      macro expansion producing 'defined' has undefined behavior
      [-Werror,-Wexpansion-to-defined]
/Users/christian/Downloads/exhale-master/src/app/../../src/app/exhaleApp.cpp:64:88: note:
      expanded from macro 'EA_USE_WORK_DIR'
  ...(defined (_WIN32) || defined (WIN32) || defined (_WIN64) || defined (WIN...
                                                                 ^
/Users/christian/Downloads/exhale-master/src/app/../../src/app/exhaleApp.cpp:628:5: error:
      macro expansion producing 'defined' has undefined behavior
      [-Werror,-Wexpansion-to-defined]
#if EA_USE_WORK_DIR
    ^
/Users/christian/Downloads/exhale-master/src/app/../../src/app/exhaleApp.cpp:64:29: note:
      expanded from macro 'EA_USE_WORK_DIR'
#define EA_USE_WORK_DIR    (defined (_WIN32) || defined (WIN32) || defin...
                            ^
/Users/christian/Downloads/exhale-master/src/app/../../src/app/exhaleApp.cpp:628:5: error:
      macro expansion producing 'defined' has undefined behavior
      [-Werror,-Wexpansion-to-defined]
/Users/christian/Downloads/exhale-master/src/app/../../src/app/exhaleApp.cpp:64:49: note:
      expanded from macro 'EA_USE_WORK_DIR'
#define EA_USE_WORK_DIR    (defined (_WIN32) || defined (WIN32) || defin...
                                                ^
/Users/christian/Downloads/exhale-master/src/app/../../src/app/exhaleApp.cpp:628:5: error:
      macro expansion producing 'defined' has undefined behavior
      [-Werror,-Wexpansion-to-defined]
/Users/christian/Downloads/exhale-master/src/app/../../src/app/exhaleApp.cpp:64:68: note:
      expanded from macro 'EA_USE_WORK_DIR'
#define EA_USE_WORK_DIR    (defined (_WIN32) || defined (WIN32) || defined (_WIN...
                                                                   ^
/Users/christian/Downloads/exhale-master/src/app/../../src/app/exhaleApp.cpp:628:5: error:
      macro expansion producing 'defined' has undefined behavior
      [-Werror,-Wexpansion-to-defined]
/Users/christian/Downloads/exhale-master/src/app/../../src/app/exhaleApp.cpp:64:88: note:
      expanded from macro 'EA_USE_WORK_DIR'
  ...(defined (_WIN32) || defined (WIN32) || defined (_WIN64) || defined (WIN...
                                                                 ^
/Users/christian/Downloads/exhale-master/src/app/../../src/app/exhaleApp.cpp:1098:5: error:
      macro expansion producing 'defined' has undefined behavior
      [-Werror,-Wexpansion-to-defined]
#if EA_USE_WORK_DIR
    ^
/Users/christian/Downloads/exhale-master/src/app/../../src/app/exhaleApp.cpp:64:29: note:
      expanded from macro 'EA_USE_WORK_DIR'
#define EA_USE_WORK_DIR    (defined (_WIN32) || defined (WIN32) || defin...
                            ^
/Users/christian/Downloads/exhale-master/src/app/../../src/app/exhaleApp.cpp:1098:5: error:
      macro expansion producing 'defined' has undefined behavior
      [-Werror,-Wexpansion-to-defined]
/Users/christian/Downloads/exhale-master/src/app/../../src/app/exhaleApp.cpp:64:49: note:
      expanded from macro 'EA_USE_WORK_DIR'
#define EA_USE_WORK_DIR    (defined (_WIN32) || defined (WIN32) || defin...
                                                ^
/Users/christian/Downloads/exhale-master/src/app/../../src/app/exhaleApp.cpp:1098:5: error:
      macro expansion producing 'defined' has undefined behavior
      [-Werror,-Wexpansion-to-defined]
/Users/christian/Downloads/exhale-master/src/app/../../src/app/exhaleApp.cpp:64:68: note:
      expanded from macro 'EA_USE_WORK_DIR'
#define EA_USE_WORK_DIR    (defined (_WIN32) || defined (WIN32) || defined (_WIN...
                                                                   ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
make[1]: *** [../../build/exhaleApp.r.o] Error 1
make: *** [release] Error 2
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-03-27 01:54:17
https://f.losno.co/exhale-v1.1.3-7-g760f862.zip

Enabled the workaround mentioned above, apparently something went wrong with the existing define for celona? I just set the whole macro to 1.

Universal x86_64 / arm64 build, as usual. exhaled unstripped but signed, exhale stripped and signed. Hardened runtime. Notarized. (And in case anyone asks, you can't staple CLI executables.)
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-03-27 02:04:08
Universal x86_64 / arm64 build, as usual. exhaled unstripped but signed, exhale stripped and signed. Hardened runtime. Notarized. (And in case anyone asks, you can't staple CLI executables.)

Thanks, I only use the command line compiler and I don't know how to do it. In the meantime I have verified that it works with Linux, I leave you the usual version for SoC ARM v7l: exhale@760f862f-Linux-armv7l.bz2 (http://celona.altervista.org/exhale/760f862f/exhale_760f862f-Linux-armv7l.bz2).
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-03-27 02:20:26
Here ya go:

https://gist.github.com/kode54/b4f31ccf1ec8fc2c008eb80522d35e64

Basically, you need all the compile and link command lines to have -arch arguments for every arch you're building or linking. I patched the Makefiles to accept a config switch to turn that on:

Code: [Select]
make UNIVERSAL2=1

Apply it while cd'd into the exhale root dir on current as of this post commit, like so:

Code: [Select]
patch -Np1 -I path/to/exhale_universal2_workdir.patch

And as I said before, for signing:

Code: [Select]
codesign -s <identity> --option=runtime bin/exhale

That much gets you either ad-hoc or not-notarized Developer ID. This document outlines how to manually zip up and submit the resulting code signed and hardened runtime binaries to Apple for notarization. I basically sent them the exact ZIP I uploaded above.

https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution/customizing_the_notarization_workflow
Title: Re: exhale - Open Source USAC encoder
Post by: jaybeee on 2021-03-27 09:07:50
...
So I made a new commit which (1) mentions exhale's Wiki in the ReadMe (explaining the presets and listing the associated bit-rate ranges)
Chris
Thank you for that Chris. I feel silly now for not even seeing the wiki and the preset info (https://gitlab.com/ecodis/exhale/-/wikis/faq#how-does-the-bit-rate-mode-of-the-exhale-application-or-library-work)  :-[
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2021-03-27 18:23:00
Intel compiles of exhale-V1.1.4-27e9e9e0 now at Rarewares. :)
Title: Re: exhale - Open Source USAC encoder
Post by: m14u on 2021-03-27 20:01:35
i can not reproduce the "not-a-bug-a-feature" "random search noise in [a..g] modes".
Title: Re: exhale - Open Source USAC encoder
Post by: Kraeved on 2021-03-27 21:47:39
Intel compiles of exhale-V1.1.4-27e9e9e0 now at Rarewares. :)
Dear john33, take a peek at the attached screenshot of Rarewares. I highlighted the possible click points in yellow. Do you realize that an ordinary user has to examine the menu and make a few bad choices (starting with Downloads, which leads to the same News page) before Exhale would be found? Why do you torture users like that instead of linking news items to proper site sections at least? O Hypertext (https://en.wikipedia.org/wiki/Hypertext), where art thou?

C.R.Helmrich
Path bug is fixed.
Unicode bug is still there.
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-03-27 21:48:02
The new 27e9e9e0 commit of Exhale can be compiled without errors in macOS e Linux.

exhale/27e9e9e0/Linux-armv7l.bz2 (http://celona.altervista.org/exhale/27e9e9e0/Linux-armv7l.bz2)
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-03-28 02:40:05
The automatic option # set as the alias of 3 up to 48 kHz is the best choice and certainly the least sophisticated. To convince myself I have listened 5s by Paolo Balestri (https://www.youtube.com/user/paolobalestri), the male voice that puts the encoder in trouble reading Dorian Gray in Italian, sampled at each frequency used by Exhale. I am sure that will also be needed in the future because after recalibrating the encoder on this voice, the higher bitrates with the higher sample rates now show problems that I had missed.

Mono wave files
7350Hz (http://celona.altervista.org/exhale/paolo.balestri/dry/mono/7350Hz.wav) - 8000Hz (http://celona.altervista.org/exhale/paolo.balestri/dry/mono/8000Hz.wav) - 11025Hz (http://celona.altervista.org/exhale/paolo.balestri/dry/mono/11025Hz.wav) - 12000Hz (http://celona.altervista.org/exhale/paolo.balestri/dry/mono/12000Hz.wav) - 16000Hz (http://celona.altervista.org/exhale/paolo.balestri/dry/mono/16000Hz.wav) - 19200Hz (http://celona.altervista.org/exhale/paolo.balestri/dry/mono/19200Hz.wav) - 22050Hz (http://celona.altervista.org/exhale/paolo.balestri/dry/mono/22050Hz.wav) - 24000Hz (http://celona.altervista.org/exhale/paolo.balestri/dry/mono/24000Hz.wav) - 32000Hz (http://celona.altervista.org/exhale/paolo.balestri/dry/mono/32000Hz.wav) - 38400Hz (http://celona.altervista.org/exhale/paolo.balestri/dry/mono/38400Hz.wav) - 44100Hz (http://celona.altervista.org/exhale/paolo.balestri/dry/mono/44100Hz.wav) - 48000Hz (http://celona.altervista.org/exhale/paolo.balestri/dry/mono/48000Hz.wav) - 57600Hz (http://celona.altervista.org/exhale/paolo.balestri/dry/mono/57600Hz.wav) - 64000Hz (http://celona.altervista.org/exhale/paolo.balestri/dry/mono/64000Hz.wav) - 88200Hz (http://celona.altervista.org/exhale/paolo.balestri/dry/mono/88200Hz.wav) - 96000Hz (http://celona.altervista.org/exhale/paolo.balestri/dry/mono/96000Hz.wav) .

Stereo wave files
7350Hz (http://celona.altervista.org/exhale/paolo.balestri/dry/stereo/7350Hz.wav) - 8000Hz (http://celona.altervista.org/exhale/paolo.balestri/dry/stereo/8000Hz.wav) - 11025Hz (http://celona.altervista.org/exhale/paolo.balestri/dry/stereo/11025Hz.wav) - 12000Hz (http://celona.altervista.org/exhale/paolo.balestri/dry/stereo/12000Hz.wav) - 16000Hz (http://celona.altervista.org/exhale/paolo.balestri/dry/stereo/16000Hz.wav) - 19200Hz (http://celona.altervista.org/exhale/paolo.balestri/dry/stereo/19200Hz.wav) - 22050Hz (http://celona.altervista.org/exhale/paolo.balestri/dry/stereo/22050Hz.wav) - 24000Hz (http://celona.altervista.org/exhale/paolo.balestri/dry/stereo/24000Hz.wav) - 32000Hz (http://celona.altervista.org/exhale/paolo.balestri/dry/stereo/32000Hz.wav) - 38400Hz (http://celona.altervista.org/exhale/paolo.balestri/dry/stereo/38400Hz.wav) - 44100Hz (http://celona.altervista.org/exhale/paolo.balestri/dry/stereo/44100Hz.wav) - 48000Hz (http://celona.altervista.org/exhale/paolo.balestri/dry/stereo/48000Hz.wav) - 57600Hz (http://celona.altervista.org/exhale/paolo.balestri/dry/stereo/57600Hz.wav) - 64000Hz (http://celona.altervista.org/exhale/paolo.balestri/dry/stereo/64000Hz.wav) - 88200Hz (http://celona.altervista.org/exhale/paolo.balestri/dry/stereo/88200Hz.wav) - 96000Hz (http://celona.altervista.org/exhale/paolo.balestri/dry/stereo/96000Hz.wav) .

I saved a set of files with fewer sampling rates, only in mono, processed or rather over-processed, to try to better understand the influence of extreme levels (-16LUFS) in the result.

Processed mono wave files
12000Hz (http://celona.altervista.org/exhale/paolo.balestri/processed/mono/12000Hz.wav) - 16000Hz (http://celona.altervista.org/exhale/paolo.balestri/processed/mono/16000Hz.wav) - 24000Hz (http://celona.altervista.org/exhale/paolo.balestri/processed/mono/24000Hz.wav) - 32000Hz (http://celona.altervista.org/exhale/paolo.balestri/processed/mono/32000Hz.wav) - 44100Hz (http://celona.altervista.org/exhale/paolo.balestri/processed/mono/44100Hz.wav) - 48000Hz (http://celona.altervista.org/exhale/paolo.balestri/processed/mono/48000Hz.wav) - 88200Hz (http://celona.altervista.org/exhale/paolo.balestri/processed/mono/88200Hz.wav) - 96000Hz (http://celona.altervista.org/exhale/paolo.balestri/processed/mono/96000Hz.wav) .

I have used these files with other encoders too and of course the differences are very small, but it's better to postpone these evaluations.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-03-28 11:52:17
Unicode bug is still there.
Hmm, just discovered something strange. The Windows 7 command prompt does not display Unicode properly because the default cmd font isn't Unicode capable, at least on my German Windows installation. Right-click on a cmd window's title bar, select "Properties" and select font "Consolas". Then I can see and encode existing Unicode-named files and can also give the output .m4a a Unicode name.

Can you rename an existing .wav file to the Russian word (music) in your screenshot and try encoding that file? Maybe it's just exhale's "not found" error message that's buggy.

i can not reproduce the "not-a-bug-a-feature" "random search noise in [a..g] modes".
That's great news, so kode54's last fixes to his packet decoder actually fixed that issue, it seems.

Thank you for that Chris. I feel silly now for not even seeing the wiki and the preset info (https://gitlab.com/ecodis/exhale/-/wikis/faq#how-does-the-bit-rate-mode-of-the-exhale-application-or-library-work)  :-[
Igor actually already linked to the Wiki in the very first post (https://hydrogenaud.io/index.php?topic=118888.0) of this thread ;) But I don't blame you, really, the thread has gotten much too long. Maybe I should open a separate thread for bug reports? But then again, we have the GitLab issue tracker for that, which I actually prefer since contributors can link to merge requests there with concrete source code fixes.

Maybe I'll just ask Igor or a moderator to augment the first post of this thread to display a big "PLEASE READ THE FIRST 10 POSTS OF THIS THREAD FIRST BEFORE POSTING A QUESTION OR BUG REPORT!" sign?

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: Kraeved on 2021-03-28 13:06:53
Maybe it's just exhale's "not found" error message that's buggy.

Exhale processes Unicode filenames on Windows 7 just fine, Unicode bug is related to the error message only.
Use non-existing path and filename to reproduce the bug: exhale g c:\Небо\птицы-vögel-pájaros-birds.wav out.m4a
Then it outputs ERROR while trying to open input file c:\????\?????-v�gel-p�jaros-birds.wav! Does it already exist?
Its garbled look is barely related to the fonts as I’ve seen this earlier when something is broken (of course, I tried Consolas etc).
Title: Re: exhale - Open Source USAC encoder
Post by: Case on 2021-03-28 16:06:31
You should be able to fix Unicode output with https://stackoverflow.com/a/9051543 (https://stackoverflow.com/a/9051543).
Title: Re: exhale - Open Source USAC encoder
Post by: Kamedo2 on 2021-03-28 17:26:12
I am planning a personal listening test of the latest exhale and the Opus encoder.
Exhale will be tested with and without the SBR.
If nothing is wrong, I'm going to start testing from 2021/04/03.
(https://listening-test.coresv.net/img2/planned-listening-test-small.png)
Below is the bitrate table of the tested samples in bps.
Code: [Select]
length[sec]	exhale.c.64k	exhale.1.64k	opus.62k	exhale.e.88k	exhale.2.80k	opus.80k	filename
28.302449 81199 80218 73541 104028 96833 95249 10xh_.wav
11.878571 58106 70776 82934 82409 85669 103687 11ff_.wav
8.252063 67404 76656 70562 93430 93945 90624 12at_.wav
10.030998 68502 72969 67597 90542 88539 86942 13by_.wav
15.000771 69271 72271 83964 95502 89230 107602 14fe_.wav
29.206599 64635 77163 65405 87770 90984 83760 15ma_.wav
8.252063 61219 63194 67762 84183 77129 84811 16mb_.wav
11.878571 71365 75570 73479 97155 91817 94913 17qu_.wav
15.471701 72109 84782 72357 95125 99839 92233 18vr_.wav
30.291701 67653 70099 72197 94803 85964 92551 19am_.wav
30.000023 65889 70826 63895 88973 85863 83000 20tt_.wav
19.187347 68295 74314 72916 92831 90621 93070 21wa_.wav
29.908549 67638 69377 67815 92090 84703 86549 22ex_.wav
11.902381 63394 70436 67855 83817 85528 87487 23ht_.wav
19.144354 64523 69441 68512 90219 85566 82994 24td_.wav
24.493991 69405 76047 78994 94019 90768 103220 01 castanets.wav
20.004422 79211 89677 90460 100253 104521 117074 02 fatboy_30sec.wav
17.468027 75990 78370 82867 107020 95468 107081 03 eig.wav
20.38093 68243 87039 86735 87674 104426 109700 04 Bachpsichord.wav
28.230771 64572 72773 69926 86566 88835 89108 05 Enola.wav
10.329887 57987 69040 83625 87132 85543 106781 06 trumpet.wav
25.097959 72506 75534 75347 97080 92273 95983 07 applaud.wav
29.018934 86717 75998 69710 109027 92649 91347 08 velvet.wav
20.154921 62957 61911 59436 85728 76115 75877 09 Linchpin.wav
20.006735 65768 77281 75511 87071 91216 95042 10 spill_the_blood.wav
28.405918 59437 55188 56687 85110 70100 67418 11 female_speech.wav
19.858322 69985 69321 73034 95719 85483 93052 12 French_Ad.wav
20.07996141 68295.55556 73565.59259 73078.62963 92417.62963 89245.44444 93227.96296 27_TESTED_SAMPLE_TRACKS_AVERAGE

300 61085 66806 63464 85342 81479 81510 Album Average
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-03-28 18:14:32
You should be able to fix Unicode output with https://stackoverflow.com/a/9051543 (https://stackoverflow.com/a/9051543).
Thanks, I just noticed the same suggestion on a different web page, but it doesn't work, at least not with my VS2012 compiler. See also my reply to https://gitlab.com/ecodis/exhale/-/issues/17. Also, I had to finish this release since somebody is waiting for me, so

the 27e9e9e revision is now the tagged final 1.1.4 release of exhale.

Changes since exhale 1.1.3 from last month:

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: sveakul on 2021-03-29 00:56:49
I am planning a personal listening test of the latest exhale and the Opus encoder.
Exhale will be tested with and without the SBR.
If nothing is wrong, I'm going to start testing from 2021/04/03.
Looking forward to this, thank you.  It would be of great interest to me (and maybe others?) if you could add one high bitrate test at 192 kbs for both codecs for a vocals-with-music source to check how the "9" encoding level of Exhale performs against Opus.
Title: Re: exhale - Open Source USAC encoder
Post by: nu774 on 2021-03-29 01:57:13
By C/C++ standard, mixing char/wchar_t output to a same stdio file / iostream is not guaranteed to work.
https://stackoverflow.com/questions/8947949/mixing-cout-and-wcout-in-same-program

IIRC, in case of MSVC mixing them is allowed only when _O_U8TEXT/_O_U16TEXT is NOT set.
In other words, if you want to use _O_U8TEXT/_O_U16TEXT in MSVC, you have to stick to wchar_t oriented printing functions everywhere.
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-03-29 02:01:43
It would be of great interest to me (and maybe others?) if you could add one high bitrate test at 192 kbs for both codecs for a vocals-with-music source to check how the "9" encoding level of Exhale performs against Opus.

1mindemo (http://www.paladino.ct.it/1mindemo.zip) - CAF file contain Opus with only CELT based on MDCT.
Title: Re: exhale - Open Source USAC encoder
Post by: Jurgga on 2021-03-29 09:47:45
Exhale 1.1.4 DLLs for EZ CD Audio Converter:

https://download.poikosoft.com/Exhale-1.1.4.zip
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2021-03-29 10:40:48
exhale v1.1.4-27e9e9e0 {Stable}
Built on March 28, 2021, GCC 10.2.0

https://gitlab.com/ecodis/exhale/-/releases
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-03-29 20:26:13
exhale v1.1.4-27e9e9e0 {Stable} {macOS} {Universal}
Built on March 29, 2021, clang 12.0.0 (clang-1200.0.32.29)
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-03-30 00:22:26
By C/C++ standard, mixing char/wchar_t output to a same stdio file / iostream is not guaranteed to work.
... you have to stick to wchar_t oriented printing functions everywhere.
nu774, you saved the day (once again). :) The combination of your and Case's suggestion (for stderr instead of stdout in my case) does the trick. So thanks again to both of you. Now I just need to figure out how to shorten all these printfs... With all the #ifdef ...WCHAR, #else duplications, the code in exhaleApp.cpp has gotten nearly unreadable. Spaghetti code, indeed.

Basically, you need all the compile and link command lines to have -arch arguments for every arch you're building or linking. I patched the Makefiles to accept a config switch to turn that on:
Code: [Select]
make UNIVERSAL2=1
Is that something I should be committing to my main Git branch? Sounds like it could save people some time when updating their Mac binaries after a new exhale release.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-03-30 00:55:00
Probably totally safe to do, for now. It can build with that option on Xcode 12.2 or later, or the command line tools for 12.2 or later. Otherwise, it will default to building whatever the current machine's architecture is, and it will default the target version to the maximum supported by the currently installed SDK.
Title: Re: exhale - Open Source USAC encoder
Post by: Kraeved on 2021-03-30 04:22:13
C.R.Helmrich
Unicode bug mutated a bit, but is still there. For example, question marks are gone, but no actual symbols are displayed.

celona
Decifra questo codice e goditi il capolavoro :D aHR0cHM6Ly9vc2hpLmF0L3hzUGdlRSANCg==
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-03-30 04:42:26
Very clever link obfuscation, my dude. I approve.

Edit: Please try running it under Windows Terminal. No, I am not joking, this is literally what the app is called. You may find it either in the Microsoft Store, or on Microsoft's Github project page for it. CHCP isn't needed to run Unicode apps under the terminal, it only changes what 8 bit encoding is used for ANSI API. And incidentally, Windows 10 20H1 is the first version of Windows to support UTF-8 for that, and not just consider it a hack.
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-03-30 06:12:56
celona
Decifra questo codice e goditi il capolavoro :D aHR0cHM6Ly9vc2hpLmF0L3hzUGdlRSANCg==

Why me? I chose not to hurt myself, I have been using UTF-8 since 1999 when I discovered an operating system called BeOS R4.5.
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-03-30 07:55:41
It's a base64 encoded short URL that leads to a lovely download, but I'm not sure our forum can allow it to stay forever.
Title: Re: exhale - Open Source USAC encoder
Post by: Kamedo2 on 2021-03-30 18:10:19
It would be of great interest to me (and maybe others?) if you could add one high bitrate test at 192 kbs for both codecs for a vocals-with-music source to check how the "9" encoding level of Exhale performs against Opus.
Unfortunately, testing modern codecs at 192kbps is very costly since they will be very close to the original. It won't fit in my two-month budget. IgorC already tested on xHE-AAC 1.0.7.0 -m 9 (~192 kbps) vs Opus 1.3.1 -b 182, with 12 music samples, and Opus was rated 5.0 for all the 12 samples, while xHE-AAC was transparent on only 7 samples.
https://hydrogenaud.io/index.php?topic=120007
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-03-30 22:27:45
C.R.Helmrich
Unicode bug mutated a bit, but is still there. For example, question marks are gone, ...
Patience, please. I haven't changed anything publicly yet, busy with other stuff this week.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: sveakul on 2021-03-31 00:44:04
Unfortunately, testing modern codecs at 192kbps is very costly since they will be very close to the original. It won't fit in my two-month budget. IgorC already tested on xHE-AAC 1.0.7.0 -m 9 (~192 kbps) vs Opus 1.3.1 -b 182, with 12 music samples, and Opus was rated 5.0 for all the 12 samples, while xHE-AAC was transparent on only 7 samples.
https://hydrogenaud.io/index.php?topic=120007
Thanks Kamedo2 for the reply and for pointing me to IgorC's test which somehow I missed, much appreciated!
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-04-01 00:26:03
OK, so all my attempts to save some code lines by putting all printfs into a universal Unicode/non-Unicode function or macro either didn't work (e.g. because of the L"..." wide-string prefix) or actually increased the number of code lines. So here it is (https://gitlab.com/ecodis/exhale/-/commit/d59780dc) in Spaghetti flavor. But at least it seems to work fine in a Windows command prompt. Please report back if the issue still persists somewhere.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-04-01 02:36:50
You can make L prefixes for strings by going
#define somemacro(string) L##string

Or did that break?

Don't forget that if you're using the wchar_t / L"" variants of printf, you also need to supply wchar_t strings for all %s arguments.
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2021-04-01 10:38:21
Intel compiles of exhale-V1.1.4-d59780dc now at Rarewares. :)
Title: Re: exhale - Open Source USAC encoder
Post by: Kraeved on 2021-04-01 14:43:36
Unicode bug has been fixed. Hooray!
P.S. There is a superfluous space in the timestamp.

@kode54 Windows Terminal is about Windows 10, the very OS I won’t use in the foreseeable future, no matter how hard the Silicon Valley hegemon tries to exhort.
Title: Re: exhale - Open Source USAC encoder
Post by: capma on 2021-04-01 16:23:28
I think it's not a bug but an intention, formatting with fixed width font used in console ;)
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2021-04-01 16:50:17
exhale v1.1.4-Git-d59780dc
Built on April 01, 2021, GCC 10.2.0
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-04-01 19:05:57
There is a superfluous space in the timestamp.
I think it's not a bug but an intention, formatting with fixed width font used in console ;)
Jup. Well, not really an intention here, but the predefined __DATE__ macro which I'm using for that purpose does it like that and isn't under my control.

You can make L prefixes for strings by going
#define somemacro(string) L##string
Oh cool, thanks a lot for that hint! With that I got a macro cleanup to work. Just committed that, rev. c3a9038 (see Update below). Note that, in that commit, I also fixed a minor issue with a double-backslash display ("ERROR while trying to open input file C:\\file") when the current working directory is a drive root, e.g., C:\. For some reason encoding still worked, though.

Update: I also committed (https://gitlab.com/ecodis/exhale/-/commit/cc4151b9) kode54's extension of the make system now, adding support for building Mac Universal2 binaries by specifying UNIVERSAL2=1 when calling make. Please let me know if I committed the code proposal correctly.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-04-01 21:19:15
@kode54 Windows Terminal is about Windows 10, the very OS I won’t use in the foreseeable future, no matter how hard the Silicon Valley hegemon tries to exhort.
Then buy some other third party terminal that does support Unicode and terminal formatting. And you may as well also buy extended support for your obsolete OS, to get a few more years out of it until you eventually switch to Linux.
Title: Re: exhale - Open Source USAC encoder
Post by: fabiorug on 2021-04-02 10:34:45
Why exhale does scratches with every versions especially when it's slow? Does it need a powerful CPU, not a dual core with old archictecture? Sorry if it's offtopic. I have x5  speed on foobar2000
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2021-04-02 17:41:40
exhale v1.1.4-Git-cc4151b9
Built on April 02, 2021, GCC 10.2.0

https://gitlab.com/ecodis/exhale/-/commits/master
Title: Re: exhale - Open Source USAC encoder
Post by: Kraeved on 2021-04-02 21:00:12
$ wc -c exhale*.exe | column -t
686080  exhale-john33.exe
1164800 exhale-netranger.exe

$ exhale 1 in.150M.wav out.m4a


timejohn33netranger
User 
Kernel  
Process 
Clock
20.982s
 1.684s
22.666s
22.820s
24.726s
 1.638s
26.364s
26.695s
Profiled with Procprofile (https://encode.su/threads/1838-Command-Line-Process-Profiling-Tool?s=56cf4f680ce4f2f70e6e076e0b47f585&p=35998&viewfull=1#post35998) 1.5.1 and (just in case you need a cross-platform tool with less verbose output) TimeIt (https://github.com/choksheak/timeit/)  0.1.20160422.
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-04-02 23:06:05
Why exhale does scratches with every versions especially when it's slow? Does it need a powerful CPU, not a dual core with old archictecture? Sorry if it's offtopic. I have x5  speed on foobar2000

For instance, I get 10x encode speed on my Ryzen 7 2700, but >150x decode speed using the foo_pd_aac component.
Title: Re: exhale - Open Source USAC encoder
Post by: IgorC on 2021-04-03 00:55:10
I believe you are right and broadcasters have new rules this year (see https://www.etsi.org/deliver/etsi_es/201900_201999/201980/04.02.01_60/es_201980v040201p.pdf (https://www.etsi.org/deliver/etsi_es/201900_201999/201980/04.02.01_60/es_201980v040201p.pdf))

Indeed, the DRM standard linked to by celona (thanks!) recommends PS only in the range 18 - 26 kbit/s (see sec. 5.4.3), and I second that recommendation.
Thank You both for pointing out!



Maybe I'll just ask Igor or a moderator to augment the first post of this thread to display a big "PLEASE READ THE FIRST 10 POSTS OF THIS THREAD FIRST BEFORE POSTING A QUESTION OR BUG REPORT!" sign?
@Chris, @kode54
Please feel free to edit the first post in any way You like. 
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-04-03 01:03:52
Notice added, as was exactly suggested by Chris.

New binaries with the minor Unicode change, which doesn't affect macOS builds anyway, but whatever.

https://f.losno.co/exhale-v1.1.4-3-gcc4151b.zip

Timing information from various machines:

Dad's iMac: Intel(R) Core(TM) i5-4570R CPU @ 2.70GHz / 8GB RAM
MBP: Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz
Mac mini: Apple M1

timeDad's iMacMBPMac mini (Rosetta)Mac mini (Native)
User 
System  
CPU 
Total
244.57s
3.58s
99%
4:08.21
230.15s
4.58s
99%
3:55.41
161.82s
5.62s
96%
2:54.23
132.07s
5.24s
94%
2:25.47
Corpus: Hiroki Kikuta - Secret of Mana+
Duration: 00:49:26.89
Sample rate: 44100Hz
Sample format: 16 bit
Channels: stereo
Audio MD5: 02F7A079C8D1B037C111162FA3B4CDBF

Command line: exhale 1 01\ -\ Secret\ of\ Mana.wav 01\ -\ Secret\ of\ Mana.m4a
Title: Re: exhale - Open Source USAC encoder
Post by: IgorC on 2021-04-03 01:25:16
Notice added, as was exactly suggested by Chris.
Thank You.

I am planning a personal listening test of the latest exhale and the Opus encoder.
Exhale will be tested with and without the SBR.
If nothing is wrong, I'm going to start testing from 2021/04/03.
(https://listening-test.coresv.net/img2/planned-listening-test-small.png)
Below is the bitrate table of the tested samples in bps.
Code: [Select]
length[sec]	exhale.c.64k	exhale.1.64k	opus.62k	exhale.e.88k	exhale.2.80k	opus.80k	filename
28.302449 81199 80218 73541 104028 96833 95249 10xh_.wav
11.878571 58106 70776 82934 82409 85669 103687 11ff_.wav
8.252063 67404 76656 70562 93430 93945 90624 12at_.wav
10.030998 68502 72969 67597 90542 88539 86942 13by_.wav
15.000771 69271 72271 83964 95502 89230 107602 14fe_.wav
29.206599 64635 77163 65405 87770 90984 83760 15ma_.wav
8.252063 61219 63194 67762 84183 77129 84811 16mb_.wav
11.878571 71365 75570 73479 97155 91817 94913 17qu_.wav
15.471701 72109 84782 72357 95125 99839 92233 18vr_.wav
30.291701 67653 70099 72197 94803 85964 92551 19am_.wav
30.000023 65889 70826 63895 88973 85863 83000 20tt_.wav
19.187347 68295 74314 72916 92831 90621 93070 21wa_.wav
29.908549 67638 69377 67815 92090 84703 86549 22ex_.wav
11.902381 63394 70436 67855 83817 85528 87487 23ht_.wav
19.144354 64523 69441 68512 90219 85566 82994 24td_.wav
24.493991 69405 76047 78994 94019 90768 103220 01 castanets.wav
20.004422 79211 89677 90460 100253 104521 117074 02 fatboy_30sec.wav
17.468027 75990 78370 82867 107020 95468 107081 03 eig.wav
20.38093 68243 87039 86735 87674 104426 109700 04 Bachpsichord.wav
28.230771 64572 72773 69926 86566 88835 89108 05 Enola.wav
10.329887 57987 69040 83625 87132 85543 106781 06 trumpet.wav
25.097959 72506 75534 75347 97080 92273 95983 07 applaud.wav
29.018934 86717 75998 69710 109027 92649 91347 08 velvet.wav
20.154921 62957 61911 59436 85728 76115 75877 09 Linchpin.wav
20.006735 65768 77281 75511 87071 91216 95042 10 spill_the_blood.wav
28.405918 59437 55188 56687 85110 70100 67418 11 female_speech.wav
19.858322 69985 69321 73034 95719 85483 93052 12 French_Ad.wav
20.07996141 68295.55556 73565.59259 73078.62963 92417.62963 89245.44444 93227.96296 27_TESTED_SAMPLE_TRACKS_AVERAGE

300 61085 66806 63464 85342 81479 81510 Album Average
Great! That will be very useful as we're strongly agree that SBR must be used at 48 kbps, though it's not clear if it should be at 60-80 kbps.

Only one thing to comment. No-SBR exhale mode 1 (~64 kbps) will require resampling to 32 kHz. foobar2000's dbpoweramp/SSRC resampler or SoX VHQ + 99% passband are the ones which preserve almost all frequencies, extremely close to 16 kHz and should be used for both, encoding and decoding, during a prep of files for ABX sessions.   I've used SoX VHQ + 99% passband in previous test https://hydrogenaud.io/index.php?topic=119227.0
and https://hydrogenaud.io/index.php?topic=118888.msg983108#msg983108
Title: Re: exhale - Open Source USAC encoder
Post by: Kraeved on 2021-04-03 10:29:05

  samples             exhale 1 32kHz   exhale 1 44kHz   opus vbr 64     flac      
 ------------------- ---------------- ---------------- ---------------- ----------------
  George Michael      235 602          231 870          232 397          3 637 717 
  Loreena McKennitt   272 783          269 062          277 449          3 513 477 
  Øystein Sevåg       229 935          238 929          293 827          2 753 136 


@kode54 Windows Terminal is about Windows 10, the very OS I won’t use in the foreseeable future, no matter how hard the Silicon Valley hegemon tries to exhort.
Then buy some other third party terminal that does support Unicode and terminal formatting. And you may as well also buy extended support for your obsolete OS, to get a few more years out of it until you eventually switch to Linux.

Windows 7 is stable enough to serve daily needs for at least another 5–10 years, Unicode usually works as expected, patches are coming unofficially (https://translate.google.com/translate?sl=auto&tl=en&u=https://blog.simplix.info/updatepack7r2/). Even XP is still sturdy thanks to the community (https://translate.google.com/translate?sl=auto&tl=en&u=http://forum.oszone.net/thread-344358.html) efforts. Those needs exclude GPU-hungry games, and if one wants to play, there are indie gems and ScummVM & Dosbox wrappers to run soulful retro ones. As a side effect, this allows to escape the digital pollution of nowadays with gargantuan Electron-based junk like Signal Desktop (insane 2109 folders with 17862 files on disk and 350 MiB in memory seem to be acceptable for security LARPers). As for Linux-Tux, I tried that less traveled road soon after ██████ sent me a CD. It led me to a labyrinthine quagmire of incoherence between heterogeneous objects wrapped with a duct tape in a Sisyphean way. Go figure! But my LEGO days are long behind, not to mention less tolerance of verbose manuals that veil a lack of compassion for users people. This may induce an image of some hairy preacher eccentric like Richard Stallman, yet “there are more things in heaven and earth, Horatio, than are dreamt of”. Indeed, there is a plethora of seasoned folks who are immune to bulldozing by end-of-life mantras of rentier capitalism and refuse to support the planned obsolescence, as Victor Papanek would say. Deus ex machina apps, such as Exhale, postpone upgrades and reduce costs by enabling us to allocate resources more efficiently without harming our perception and environment that much, thus they fit perfectly into an eco-friendlier mindset.

Now, back to squeezing, enjoy!
Title: Re: exhale - Open Source USAC encoder
Post by: Kamedo2 on 2021-04-03 15:02:17
Great! That will be very useful as we're strongly agree that SBR must be used at 48 kbps, though it's not clear if it should be at 60-80 kbps.

Only one thing to comment. No-SBR exhale mode 1 (~64 kbps) will require resampling to 32 kHz. foobar2000's dbpoweramp/SSRC resampler or SoX VHQ + 99% passband are the ones which preserve almost all frequencies, extremely close to 16 kHz and should be used for both, encoding and decoding, during a prep of files for ABX sessions.   I've used SoX VHQ + 99% passband in previous test https://hydrogenaud.io/index.php?topic=119227.0
and https://hydrogenaud.io/index.php?topic=118888.msg983108#msg983108

Thanks for the info!
I am currently having no trouble using exhale mode 1 in 44kHz, and I am going to test mode 1 in both the 32kHz and 44kHz.
I'm going to use refalac to the 32kHz <-> 44kHz conversion, because it is a known good resampler, and it supports floating point natively.

Code: [Select]
qaac_2.71\x64\refalac64 in.wav --rate 32000 -D -b 32 -o in-32kHz.wav

exhale-V1.1.4-cc4151b9_x64\exhale c in.wav out.c.64k-44kHz.mp4
exhale-V1.1.4-cc4151b9_x64\exhale e in.wav out.e.88k-44kHz.mp4
exhale-V1.1.4-cc4151b9_x64\exhale 1 in.wav out.1.64k-44kHz.mp4
exhale-V1.1.4-cc4151b9_x64\exhale 1 in-32kHz.wav out.1.64k-32kHz.mp4
exhale-V1.1.4-cc4151b9_x64\exhale 2 in.wav out.2.88k-44kHz.mp4

// here use foobar2000 GUI manually to convert the xHE-AAC into wav.

qaac_2.71\x64\refalac64 out.1.64k-32kHz.wav --rate 44100 -D -b 32 -o out.1.64k-32kHz-44kHz.wav
Title: Re: exhale - Open Source USAC encoder
Post by: fabiorug on 2021-04-03 19:51:55
Hi! sorry for asking but can you compile https://gitlab.com/ecodis/exhale/-/commit/e9bd99bf848c7616fcb8d27a67e236f8cce544cd

e9bd99bf  26 Sep, 2020 1 commit for windows? thanks. I want to encode some files with preset 7 and using that encoder.
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2021-04-03 21:58:28
Here you go:

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

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

:)
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-04-03 22:50:47
Also missed that I benchmarked my same build on multiple Macs, and how soundly the M1 kicks a fairly high end Haswell's ass even in emulation.
Title: Re: exhale - Open Source USAC encoder
Post by: diizzy on 2021-04-04 01:23:21
Something that would be interesting to compare between builds would be if they generate the same result of if you get rounding errors etc in the more optimized variants. Just because something compiles and runs doesn't mean it does the correct "thing" :-)
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-04-04 01:39:01
I compared the macOS outputs from Intel Mac, M1 on Rosetta, and M1 Native. They only differ by the timestamp fields in the MP4 container, and not by any of the bitstream data.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-04-06 00:44:01
Notice added, as was exactly suggested by Chris.

New binaries with the minor Unicode change, which doesn't affect macOS builds anyway, but whatever.
Thanks very much for both. Theoretically, I could have produced a typo in the non-Windows source code during my macro cleanup, so the compile check on Mac is much appreciated.

I also get identical (disregarding the timestamps in the MPEG-4 file header) encoded files with NetRanger's gcc build and my own VS2012 build (both x64). IIRC, the Intel compiler may, due to other optimizations, produce slightly different encodings which, however, should sound the same.

Edit: forgot to reply to
Why exhale does scratches with every versions especially when it's slow? Does it need a powerful CPU, not a dual core with old archictecture?
https://gitlab.com/ecodis/exhale/-/wikis/faq#why-is-the-exhale-encoder-so-slow-is-there-a-switch-for-fast-encoding

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: itisljar on 2021-04-10 19:15:54
Hey! I wanted to update that compatibility with (at least) my Samsung A50 has been resolved - now I can seek inside song without any errors. Samsung Music player. Last time I tried with, I think, 1.0.3 and it played, but as soon as I tried to seek it would error out and skip to next song.
Title: Re: exhale - Open Source USAC encoder
Post by: soundping on 2021-04-10 21:35:49
In EZ CD Audio Converter
VBR3 (~96 kbit/s)

Smells like lossy.
Title: Re: exhale - Open Source USAC encoder
Post by: fabiorug on 2021-04-11 09:06:32
thanks for the wiki. but i meant audio scratches. with NetRanger builds usually is not audible. is exhale fault or my pc fault that uses older instructions so the problem is how it was compiled?
Title: Re: exhale - Open Source USAC encoder
Post by: fabiorug on 2021-04-11 09:34:09
Does the USAC standard supports as metadata and covert art/thumbnail a Jpeg XL faster decoding 4 file? Do you think they will support new JPEG?
-d 1.541 -s 7 --epf=3 --gaborish=1 --noise=1 --intensity_target=210 --dots=0 --faster_decoding=4
the 50° commit:  jpeg xl a1248445

Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-04-11 11:48:55
A look at the spectrogram of that file tells me that it was not created by exhale. https://www.poikosoft.com/music-converter-encoder-versions seems to confirm that, it lists a Fraunhofer xHE-AAC encoder. Interesting :)

Hey! I wanted to update that compatibility with (at least) my Samsung A50 has been resolved - now I can seek inside song without any errors. Samsung Music player. Last time I tried with, I think, 1.0.3 and it played, but as soon as I tried to seek it would error out and skip to next song.
Great news, thanks very much for sharing this information!

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-04-11 15:48:41
A look at the spectrogram of that file tells me that it was not created by exhale. https://www.poikosoft.com/music-converter-encoder-versions seems to confirm that, it lists a Fraunhofer xHE-AAC encoder. Interesting :)

They want to force me to use Windows :) Now I'm going to try it out, I bought it some time ago from Poikosoft.
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-04-11 16:38:17
It's great to the point of buying a new license from the developer. Paolo Balestri (https://hydrogenaud.io/index.php?action=dlattach;attach=19521;image)'s male voice is reproduced much better even at 24kbps in CBR mode.

However, below 40kbps it reduces the sampling frequency in VBR, while in CBR it reduces it to extremely lower bitrates, I also tried 8kbps (even 6kbps but there is too much noise).
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-04-11 17:01:46
Indeed, that encoder demonstrates xHE-AAC's full speech coding potential at low bit-rates. Attached a comparison with exhale mode 'a' at 24 kbps, 44.1 kHz sampling rate. Impressive improvement due to the ACELP speech coding core, which exhale doesn't have. Yes, VBR0 and VBR1 are coded at 38.4 kHz with Fraunhofer's encoder, it seems, so my demo was also made with CBR mode.

Chris

Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-04-11 17:23:48
It is strange but also the behavior of the Fraunhofer encoder is not very predictable. In your examples Foobar reports the use of SBR only for Exhale. Compressing at higher bitrates with the Fraunhofer encoder sometimes produces worse results and files are resampled to 32kHz or 38.4kHz.

I believe that in VBR at bitrates higher than 48kbps (or perhaps only higher than 40kbps, obviously referring to monophonic signals) you don't get great advantages from ACELP.

I would like to thank Poikosoft for providing the cheapest way of obtaining the Fraunhofer encoder on the market by even providing it as a free upgrade to previous customers, a behavior that I wanted to reward by buying their software again, and will surely get more orders in the future from my employer, because buying his software is the best way to be able to distribute content in Extended HE-AAC and avoid any disputes. I had bought it to distribute compressed audio with Exhale in the past.

With the Fraunhofer encoder I can keep the voice taking up about half the space compared to Exhale. The entry I gave as an example, but also the ones in Helmrich's file seem to feel better at 24kbps than at 40kbps when compressed with Exhale.

Going up with the bitrate, on the other hand, the two compressors apparently offer approximately the same yield.
Title: Re: exhale - Open Source USAC encoder
Post by: Jurgga on 2021-04-11 17:30:13
I think the selected encoder sample rates are tuned for best audio quality.

Celona, Christian: I am able to build the encoder that gives 44.1kHz and 48 kHz for the whole bit rate range.
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-04-11 17:35:47
What I don't understand is why if I keep 48kHz at 24kbps, raising the bitrate will resample my files to a lower rate. This behavior is difficult to predict, but the result is how you write probably better.
Title: Re: exhale - Open Source USAC encoder
Post by: Jurgga on 2021-04-11 18:41:36
What I don't understand is why if I keep 48kHz at 24kbps, raising the bitrate will resample my files to a lower rate. This behavior is difficult to predict, but the result is how you write probably better.

Please explain. Or email me. 😀
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-04-11 19:14:30
I think the selected encoder sample rates are tuned for best audio quality.

Celona, Christian: I am able to build the encoder that gives 44.1kHz and 48 kHz for the whole bit rate range.
I don't want to tell you how to configure an encoder which I didn't develop, you should definitely check back with Fraunhofer as the original developers. But I assume that, since CBR 24-kbps mono coding sounds fine to my ears, VBR1 mono coding (~32 kbps target according to EZ CD Audio Converter) and all higher VBR modes should be able to handle 44.1 kHz sampling rate.

Not sure about the stereo target modes, however, I haven't checked those yet. But they might be fine already.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-04-12 11:03:16
Please explain. Or email me. 😀
I'm asking myself the problem of not being in the proper thread, because we're talking about another encoder here. Tonight I tried all the possible combinations, but let's start with the simplest thing, the VBR mode.

The encoder performs very well. I used the usual 5s from male voice of Paolo Balestri where the defects is more evident until now and the only verification I can ask you is to check that the VBR "32kb/s" label shown in the graphic interface of EZ CD Audio converter is correct.

I leave you the files used for the tests so that you can reproduce what I write - it is the scientific method :)

In input we have a mono file sampled at 48kHz: paolo.balestri-23lufs-m-48k.wav (https://celona.altervista.org/fraunhofer/paolo.balestri-23lufs-m-48k.wav) (-23 LUFS like EBU R128 - to check because I was tired).

After compression in I get the following results:
paolo.balestri-23lufs-m-48k-vbr-12kbps.m4a (https://celona.altervista.org/fraunhofer/paolo.balestri-23lufs-m-48k-vbr-12kbps.m4a) @ 12kbps VBR setting – USAC with SBR, 12.9KB, 18kbps, 32kHz;
paolo.balestri-23lufs-m-48k-vbr-32kbps.m4a (https://celona.altervista.org/fraunhofer/paolo.balestri-23lufs-m-48k-vbr-32kbps.m4a) @ 32kbps VBR setting – USAC with SBR, 13.3KB, 18kbps, 38.4kHz;
paolo.balestri-23lufs-m-48k-vbr-40kbps.m4a (https://celona.altervista.org/fraunhofer/paolo.balestri-23lufs-m-48k-vbr-40kbps.m4a) @ 40kbps VBR setting – USAC without SBR, 31KB, 46kbps, 48kHz;
paolo.balestri-23lufs-m-48k-vbr-56kbps.m4a (https://celona.altervista.org/fraunhofer/paolo.balestri-23lufs-m-48k-vbr-56kbps.m4a) @ 56kbps VBR setting – USAC without SBR, 28.9KB, 43kbps, 48kHz;
paolo.balestri-23lufs-m-48k-vbr-72kbps.m4a (https://celona.altervista.org/fraunhofer/paolo.balestri-23lufs-m-48k-vbr-72kbps.m4a) @ 72kbps VBR setting – USAC without SBR, 35.2KB, 53kbps, 48kHz;
paolo.balestri-23lufs-m-48k-vbr-104kbps.m4a (https://celona.altervista.org/fraunhofer/paolo.balestri-23lufs-m-48k-vbr-104kbps.m4a) @ 104kbps VBR setting – USAC without SBR, 53.5KB, 83kbps, 48kHz;
paolo.balestri-23lufs-m-48k-vbr-136kbps.m4a (https://celona.altervista.org/fraunhofer/paolo.balestri-23lufs-m-48k-vbr-136kbps.m4a) @ 136kbps VBR setting – USAC without SBR, 71.9KB, 113kbps, 48kHz.

As you can see, the first two results have very similar bitrates and this offers no advantage. Furthermore, the 54kbps setting produces smaller files than the 40kbps setting and this can confuse the user who will not be able to predict how much he will get from the software.

A hypothetical problem to be verified: what would the user get who has the computer connected via USB to an external DAC that does not support 38.4kHz chosen as resampling? We should try what we get not only with Windows but also with other OS (and with many USB gadgets) and testing with Bluetooth or Wi-Fi speakers connected too (but in the latter case I don't foresee any problems). Assuming to resample at 44.1kHz as suggested by C.R. Helmrich would brush aside these doubts and diversify the bitrate obtained with different options.

On the constant bitrate tests I found more problems but I will write about it in the future. For now I will limit myself to offering you just an example to show you how the first two options produce a result similar to 24kbps CBR, which however you have chosen to keep at the sampling rate provided in input and the result is good.

paolo.balestri-23lufs-m-48k-cbr-24kbps.m4a (https://celona.altervista.org/fraunhofer/paolo.balestri-23lufs-m-48k-cbr-24kbps.m4a) @ 24kbps CBR setting – USAC without SBR, 17KB, 24kbps, 48kHz.

I have informed the author of the misuse I am making of its contents; I tried to compress one of his podcast with 12 min music and voice. in just 2 MB. In the future I will also try in stereo. The already compressed original was downloaded from here: https://youtu.be/FJkP7Ru-or0 (https://youtu.be/FJkP7Ru-or0).

podio_dei_campioni-vbr-12kbps.m4a (https://celona.altervista.org/fraunhofer/podio_dei_campioni-vbr-12kbps.m4a) @ 12kbps VBR setting – 2MB;
podio_dei_campioni-cbr-24kbps.m4a (https://celona.altervista.org/fraunhofer/podio_dei_campioni-cbr-24kbps.m4a) @ 24kbps CBR setting – 2MB;
podio_dei_campioni-vbr-32kbps.m4a (https://celona.altervista.org/fraunhofer/podio_dei_campioni-vbr-32kbps.m4a) @ 32kbps VBR setting – 2MB;
podio_dei_campioni-vbr-40kbps.m4a (https://celona.altervista.org/fraunhofer/podio_dei_campioni-vbr-40kbps.m4a) @ 40kbps VBR setting – 5MB;
podio_dei_campioni-vbr-56kbps.m4a (https://celona.altervista.org/fraunhofer/podio_dei_campioni-vbr-56kbps.m4a) @ 56kbps VBR setting – 5MB.

Again the first 3 options and the last 2 produce almost identical results.
Title: Re: exhale - Open Source USAC encoder
Post by: soundping on 2021-04-12 21:33:06
EZ CD Audio Converter was just updated.
https://www.poikosoft.com/music-converter-version-history
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-04-13 04:01:09
Thanks Jurgga, you are too fast, with the tests it is better to be slower; I just wanted to replace the 38.4kHz sub-sampling with 44.1kHz or 32kHz. I must admit that I have never found such fast feedback in any commercial software.

I tried to compare the same podcast at 12kbps CBR, the lowest bitrate for stereo signals and the result is impressive, the whole podcast takes up only 1MB, and I'm sure we can still refine the perceived quality. The preview of Extended HE-AAC in Safari is played at lower quality, download the file and listen it in the Terminal with the command afplay -q 1 filename.m4a.

il_podio_dei_campioni-stereo-12kbps.m4a (https://celona.altervista.org/fraunhofer/il_podio_dei_campioni-stereo-12kbps.m4a)

il_podio_dei_campioni-stereo-12kbps.opus (https://celona.altervista.org/fraunhofer/il_podio_dei_campioni-stereo-12kbps.opus)

I added the compressed version with Opus because I'm sure some people care.
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-04-13 04:08:17
Thanks Jurgga, you are too fast, with the tests it is better to be slower; I just wanted to replace the 38.4kHz sub-sampling with 44.1kHz or 32kHz. I must admit that I have never found such fast feedback in any commercial software.

I tried to compare the same podcast at 12kbps CBR, the lowest bitrate for stereo signals and the result is impressive, the whole podcast takes up only 1MB, and I'm sure we can still refine the perceived quality. The preview of Extended HE-AAC in Safari is played at lower quality, download the file and listen it in the Terminal with the command:
Code: [Select]
afplay -q 1 filename.m4a
il_podio_dei_campioni-stereo-12kbps.m4a (https://celona.altervista.org/fraunhofer/il_podio_dei_campioni-stereo-12kbps.m4a)

il_podio_dei_campioni-stereo-12kbps.opus (https://celona.altervista.org/fraunhofer/il_podio_dei_campioni-stereo-12kbps.opus)

I added the compressed version with Opus because I'm sure some people care.
Title: Re: exhale - Open Source USAC encoder
Post by: ManekiNeko on 2021-04-13 10:47:29
EZ CD Audio Converter was just updated.
https://www.poikosoft.com/music-converter-version-history

Nice. My go to software these days for the high quality results/ease of of use. As it can encode both Fraunhofer and exhale xHE-AAC, have the two been compared?
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-04-13 10:57:20
They tend to offer similar results at high bitrates, going down the Fraunhofer uses half the data or maybe less for similar results.
Title: Re: exhale - Open Source USAC encoder
Post by: soundping on 2021-04-14 12:22:15
EZ CD with VBR4 (~128)
Foobar with CVBR 4 (~128)
Title: Re: exhale - Open Source USAC encoder
Post by: Kraeved on 2021-04-14 13:24:42
Playback goes smooth when I seek USAC files produced by EZ CD Audio Converter with Foobar 1.6.5, fdk-acc packed decoder 1.17 and WASAPI Shared, whereas files produced by Exhale sound scratched for a second or two after changing playback position.
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-04-14 22:56:12
It is strange but also the behavior of the Fraunhofer encoder is not very predictable. In your examples Foobar reports the use of SBR only for Exhale. Compressing at higher bitrates with the Fraunhofer encoder sometimes produces worse results and files are resampled to 32kHz or 38.4kHz.
Could you please post or PM me some sample files created with FhG encoder? I do not have the funds available to buy it right now.
Title: Re: exhale - Open Source USAC encoder
Post by: guruboolez on 2021-04-15 19:07:16
Hi, I created a full set of encodings for a single sample (all 7 VBR modes and all 27 CBR modes available in EZ CDDA Converter 9.3.1 Trial Mode — from 12 to 320 kbps).
The files that appears as SBR in foobar2000 1.65 and foo_pd_aac (1.17) are CBR 40-48-56-64 kbps and VBR 1 and 2 (cf screenshot).


P.S. the zip archive below only contains <128 kbps encodings.
The full set is available for a short time on a general hoster:
https://www34.zippyshare.com/v/YOX79EMS/file.html
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-04-15 22:11:59
Thanks for that. I've updated the packet decoder with full USAC SBR signaling detection, and support for all of the SBR ratios right now. I have also tested VBR0, and found it totally not annoying. I must be going deaf.
Title: Re: exhale - Open Source USAC encoder
Post by: capma on 2021-04-16 16:13:55
I have also tested VBR0, and found it totally not annoying. I must be going deaf.
Same impressions here  :-[
Title: Re: exhale - Open Source USAC encoder
Post by: sld on 2021-04-17 09:56:08
Not deaf. Just... older.  :))
Title: Re: exhale - Open Source USAC encoder
Post by: fabiorug on 2021-04-17 11:03:24
Can you post build 16d3fbac compiled for windows 64?
sorry if i asked too much.
But anyway i think even with build that uses more bitrate i won't use less than preset 6 if I want perfect sound.


exhale v1.1.0-c71ec480 is ok at preset 2.
For preset 1 v.1.0.3-41751381 is fine.
for sbr exhale 193dc268 preset e is good compared to 1.1.4 a-b
Title: Re: exhale - Open Source USAC encoder
Post by: fabiorug on 2021-04-18 09:27:59
but I really need the build I mentioned exhale 193dc268 preset e to convert some songs
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-04-24 10:20:38
exhale v1.1.0-c71ec480 is ok at preset 2.
For preset 1 v.1.0.3-41751381 is fine.
for sbr exhale 193dc268 preset e is good compared to 1.1.4 a-b
Please don't recommend older versions of exhale, they may have bugs and/or cause seeking issues in some players. I recommend using version 1.1.4 or later. And the audio quality has not gotten worse with newer releases, trust me.

I just committed (https://gitlab.com/ecodis/exhale/-/commit/94a4ed9a) an exhale 1.1.5 release candidate containing the Unicode related fixes, the UNIVERSAL2 support in the makefile, and some other cleanups. If there are no issues with this release, I'll tag it as the final 1.1.5 release next weekend.

Playback goes smooth when I seek USAC files produced by EZ CD Audio Converter with Foobar 1.6.5, fdk-acc packed decoder 1.17 and WASAPI Shared, whereas files produced by Exhale sound scratched for a second or two after changing playback position.
That effect should be reduced a bit with this new release.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2021-04-24 12:30:42
Intel compiles of exhale-v1.1.5-RC1-94a4ed9a available here:

www.rarewares.org/files/aac/exhale-v1.1.5-RC1-94a4ed9a_x64.zip (http://www.rarewares.org/files/aac/exhale-v1.1.5-RC1-94a4ed9a_x64.zip)

www.rarewares.org/files/aac/exhale-v1.1.5-RC1-94a4ed9a_x86.zip (http://www.rarewares.org/files/aac/exhale-v1.1.5-RC1-94a4ed9a_x86.zip)

:)
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2021-04-24 20:06:14
exhale v1.1.5-RC1-94a4ed9a
Built on April 24, 2021, GCC 10.2.0
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-04-25 00:35:27
macOS builds, using UNIVERSAL2=1
Built April 24, 2021, Xcode 12.4
Title: Re: exhale - Open Source USAC encoder
Post by: guruboolez on 2021-04-27 15:16:38
I made a quick and a bit dirty blind comparison between SBR and non-SBR settings at 48 and 64 kbps. Why dirty? There are no low and high anchor first, and the evaluation process was rather quick (1…3 minutes to rank all four encodings per samples in most cases).
The test is based on the same 40 musical samples I already used before (like here (https://hydrogenaud.io/index.php?topic=120081.0). There are four groups of 10 samples (10 various and random samples from Billboard charts, 10 samples from classical music, 10 samples I select from HA.io members library — and 10 samples already knows as critical or problem samples, with a strong emphasis on transients and pre-echo).

I used 1.1.4 version from april.

The final result looks like this:

(https://zupimages.net/up/21/17/txko.png) (https://zupimages.net/viewer.php?id=21/17/txko.png)

In short, at 48 kbps and 64 kbps, there's no statistical evidence that SBR or non-SBR performs better.


But if I break the 40 selection into two different groups: 30 common musical samples and 10 critical samples, I get the following results:

(https://zupimages.net/up/21/17/3tgn.png) (https://zupimages.net/viewer.php?id=21/17/3tgn.png)

(https://zupimages.net/up/21/17/5w0g.png) (https://zupimages.net/viewer.php?id=21/17/5w0g.png)

Now it seems that common and representative samples are clearly performing better with SBR at both 48 and 64 kbps. On the other side SBR has a strong negative impact on the tested problem samples. This is not a surprise (SBR encodings have a lower time resolution and it leads to increased pre-echo). In other words, my opinion is that SBR should be prefered over non-SBR at 48 and 64 kbps with Exhale.

These results can also be compared to my personal test done last year (https://hydrogenaud.io/index.php?topic=118888.msg984385#msg984385) between 32 KHz and 44 KHz at 64 kbps. 32 KHz was better to my taste. Today, Exhale with SBR probably sound as good if not better (with a plain and full frequency sound due to SBR).


NB : average bitrate is based on ~250 hours of music. Details here (https://docs.google.com/spreadsheets/d/18lGNoBB0ZB2A4SGAw3_z-5L7gzl54MG3D_V7tf2jII8/edit#gid=219055915).
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-04-27 22:50:42
Great to have you back, Guruboolez! :) I was already waiting for such a "subjective crosscheck". Let's see what Kamedo2 comes up with in May. Meanwhile, some news regarding xHE-AAC playback in foobar2000:

- The newest foobar2000 1.6.6 release (https://www.foobar2000.org/) now features a graphical user interface for configuring exhale for conversion. Neat! Thanks again to Peter!
- The newest AAC packet decoder 1.19 (https://www.foobar2000.org/components/view/foo_pd_aac) supports 24-bit decoding and allows you to use foobar2000's excellent noise shaped dither during conversion/playback (very useful at 16-bit output). Neat as well! :) Thanks once again to Christopher!

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-04-27 22:55:16
Not just 24 bit output, 24 bit output with 7 bits of headroom for clipping. You can either choose to use ReplayGain tags to scale that back, or you can use the built-in peak limiter, which is once again set to -0.1 dB. Funny thing, I actually noticed a long track being a few points quieter, or rather, less severe ReplayGain correction, when the limiters were removed completely, and peaks were unclipped.
Title: Re: exhale - Open Source USAC encoder
Post by: synclagz on 2021-04-28 06:42:53
I made a quick and a bit dirty blind comparison between SBR and non-SBR settings at 48 and 64 kbps.

Excellent work. :)
I was just thinking today about the difference in quality between SBR vs standard mode, and I see that there is an answer already. :)
Nice.
Title: Re: exhale - Open Source USAC encoder
Post by: guruboolez on 2021-04-28 10:04:29
- The newest foobar2000 1.6.6 release (https://www.foobar2000.org/) now features a graphical user interface for configuring exhale for conversion. Neat! Thanks again to Peter!
- The newest AAC packet decoder 1.19 (https://www.foobar2000.org/components/view/foo_pd_aac) supports 24-bit decoding and allows you to use foobar2000's excellent noise shaped dither during conversion/playback (very useful at 16-bit output). Neat as well! :) Thanks once again to Christopher!

Not just 24 bit output, 24 bit output with 7 bits of headroom for clipping. You can either choose to use ReplayGain tags to scale that back, or you can use the built-in peak limiter, which is once again set to -0.1 dB.

That's really great!
On my side, I replaced my Samsung with a Poco X3 NFC. The embedded music player is playing Exhale and FhG xHE-AAC fine. I didn't encounter any issue with seeking. MX Player (which is rather a video player for Android) also works. Those apps are not as conveniant as foobar2000 mobile or Poweramp, but at least xHE-AAC starts to be really usable on mobile players.



Excellent work. :)
I was just thinking today about the difference in quality between SBR vs standard mode, and I see that there is an answer already. :)
Nice.
I'd like to go further and compare SBR and non SBR at 80 kbps (maybe 96 kbps, depending on 80 kbps results). I'm a bit annoyed though because presets don't totally match. Exhale "2" mode reachs 79,5 kbps on my large bitrate table. But on the SBR side "d" reachs 73,4 kbps and "e" 85,6 kbps. I guess I had to oppose "2" and "d". Any thoughts on this?
Title: Re: exhale - Open Source USAC encoder
Post by: synclagz on 2021-04-28 12:21:26
Excellent work. :)
I was just thinking today about the difference in quality between SBR vs standard mode, and I see that there is an answer already. :)
Nice.
I'd like to go further and compare SBR and non SBR at 80 kbps (maybe 96 kbps, depending on 80 kbps results). I'm a bit annoyed though because presets don't totally match. Exhale "2" mode reachs 79,5 kbps on my large bitrate table. But on the SBR side "d" reachs 73,4 kbps and "e" 85,6 kbps. I guess I had to oppose "2" and "d". Any thoughts on this?
I think that this is a good choice. As you discovered recently, SBR mode gives slightly better quality on low bitrate so choosing standard mode 2 vs mode d should be fair choice. Mode 2 will gain slight advantage in bitrate to compesate for slightly lower quality compared against sbr mode d. If mode d could keep up with 5-7 kbps lower bitrate to match, or even surpass mode 2 quality, than you get both quality and efficiency at slightly lower bitrate.
Should be interesting to see the results. :)
Title: Re: exhale - Open Source USAC encoder
Post by: IgorC on 2021-04-28 14:56:07
- The newest AAC packet decoder 1.19 (https://www.foobar2000.org/components/view/foo_pd_aac) supports 24-bit decoding and allows you to use foobar2000's excellent noise shaped dither during conversion/playback (very useful at 16-bit output). Neat as well! :) Thanks once again to Christopher!

Not just 24 bit output, 24 bit output with 7 bits of headroom for clipping.
You rock my day!  :))

Does it mean that previously all xHE-AAC files were decoded in 16 bits even if 24 bits decoding was enabled in foobar2000?

P.S. Thanks to Guru for testing SBR.  I was waiting for such test  for some time already.  It's great to see SBR is useful at 60 kbps.


Title: Re: exhale - Open Source USAC encoder
Post by: fabiorug on 2021-04-28 17:23:18
kode, do  you have that g94 RC for windows? even if is older than release. thanks
Title: Re: exhale - Open Source USAC encoder
Post by: fabiorug on 2021-04-28 17:35:17
what is the right link for the develop branch? can anyone view it or only the one logged in gitlab?
Title: Re: exhale - Open Source USAC encoder
Post by: guruboolez on 2021-04-28 17:39:21
I think that this is a good choice. As you discovered recently, SBR mode gives slightly better quality on low bitrate so choosing standard mode 2 vs mode d should be fair choice. Mode 2 will gain slight advantage in bitrate to compesate for slightly lower quality compared against sbr mode d. If mode d could keep up with 5-7 kbps lower bitrate to match, or even surpass mode 2 quality, than you get both quality and efficiency at slightly lower bitrate.
Should be interesting to see the results. :)
I've started the comparison between 2 and d. Thanks your your advice!
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-04-29 02:02:17
@fabiorug These two posts are literally exactly what you want:

https://hydrogenaud.io/index.php?topic=118888.msg996679#msg996679
https://hydrogenaud.io/index.php?topic=118888.msg996692#msg996692
Title: Re: exhale - Open Source USAC encoder
Post by: soundping on 2021-04-29 21:47:23
Windows Insiders build 21370

Quote
Support for AAC codec: Enjoy premium audio streaming quality wirelessly on your Bluetooth headphones and speakers with AAC codec. Short for Advanced Audio Codec, AAC is a lossy codec that delivers high quality audio streaming in smaller files – great for listening to music online.
https://blogs.windows.com/windows-insider/2021/04/29/announcing-windows-10-insider-preview-build-21370/

Including Extended High Efficiency AAC xHE-AAC – defined in 2012, uses USAC
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-04-30 10:31:53
Great news, thanks for letting us know! Was anyone able to test xHE-AAC playback on that insider build?

I just finished the stable exhale 1.1.5 release (9a1c4ee3 (https://gitlab.com/ecodis/exhale/-/releases/v1.1.5)) which, on top of the RC, improves encoding of the very last frame when using the command-line exhale.exe directly (not through e.g. foobar2000).

Changes since exhale 1.1.4 from last month:

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2021-04-30 18:36:56
Intel compiles of exhale-V1.1.5-9a1c4ee3 now at Rarewares.
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2021-04-30 20:39:49
exhale v1.1.5-9a1c4ee3
Built on April 30, 2021, GCC 10.2.0

https://gitlab.com/ecodis/exhale/-/releases
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-04-30 21:58:41
exhale v1.1.5-0-g9a1c4ee
Built on April 30, 2021, Xcode 12.5

https://gitlab.com/ecodis/exhale/-/releases
Title: Re: exhale - Open Source USAC encoder
Post by: soundping on 2021-05-01 00:30:01
exhale v1.1.5-9a1c4ee3
foobar

USAC/SBR
Error on some tracks and they're unplayable.

No errors on USAC regular mode.

Used John and NetRanger downloads and produced the same errors.
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-05-01 01:52:42
Please try again with the latest component. I fixed a regression, and updated the SDK. If it persists, please PM me a non-working file to look at.
Title: Re: exhale - Open Source USAC encoder
Post by: soundping on 2021-05-01 03:27:13
Please try again with the latest component. I fixed a regression, and updated the SDK. If it persists, please PM me a non-working file to look at.
Still having the same errors on SBR.
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-05-01 03:36:21
PM me a file that's failing, then. I suggest 0x0.st as an upload target, if you have a copy of CURL to interface with it. It's like ix.io, but also accepts binary files of most types. (Except for executables.)
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-05-01 04:05:08
Your broken file is not a valid MP4 file. In fact, it isn't a valid anything file. It appears to be random garbage.
Title: Re: exhale - Open Source USAC encoder
Post by: soundping on 2021-05-01 15:03:41
C.R.Helmrich found the problem with SBR.

Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-05-01 15:25:48
Yes, it's the same issue guruboolez and others once reported (https://hydrogenaud.io/index.php?topic=118888.msg984761#msg984761), some unreliable behavior on some Windows systems when using exhale via stdin (e.g. in foobar2000) and in parallel.

I guess I'll have to take another look at exhale's PCM reading routine in case of standard input. For now, the message linked to above describes how to configure the code to run more reliably (but slower).

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: Gravitator on 2021-05-01 17:26:26
enc v1.1.5-9a1c4ee3, dec v1.19
#a-e - poor sound quality at the output (foobar).
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-05-01 22:00:39
There may be something wrong with my SBR decoding? I need to recheck my library code.

Edit: An important fix to a regression introduced at some point: 1.21 fixes the decoder configuration not being applied to the separate decoder used for first packet analysis, which was causing the output delay to be overwritten, causing the default configuration of no PCM limiter to result in 5ms, the default limiter attack time, being chopped off of the output when the limiter is disabled. This is now fixed.

I am attempting to pass the xHE-AAC compliance tests as well, but there's a strange issue with the SBR output not being identical to a reference output. There's as much as a 0.033 peak difference between the two, and a spectral analysis of the difference shows that the spectra is entirely restricted to the SBR output.
Title: Re: exhale - Open Source USAC encoder
Post by: soundping on 2021-05-02 06:37:41
Can the quality level be adjusted?
Title: Re: exhale - Open Source USAC encoder
Post by: Porcus on 2021-05-02 07:55:43
The "Medium"? Is that assigned by dBpoweramp then?
Title: Re: exhale - Open Source USAC encoder
Post by: Kraeved on 2021-05-02 11:01:17
Dear @john33, I see one weird char on the news page of Rarewares.
Title: Re: exhale - Open Source USAC encoder
Post by: Rollin on 2021-05-02 11:41:33
When using libfdk decoder with ffmpeg for xHE-AAC files, DRC is enabled by default. Does this mean that it is enabled in fdk on Android too?
Title: Re: exhale - Open Source USAC encoder
Post by: Rollin on 2021-05-02 12:01:46
@kode54 , in AAC Packet Decoder option description for DRC reference level says that disabled is -1. But description of options for libfdk in ffmpeg says that disabled is -2 and auto is -1.
Code: [Select]
-drc_level         <int>        .D..A...... Dynamic Range Control: reference level, quantized to 0.25dB steps where [0] is 0dB and [127] is -31.75dB, -1 for auto, and -2 for disabled (from -2 to 127) (default -1)
Is description in AAC Packet Decoder correct?
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-05-02 18:13:07
Does it mean that previously all xHE-AAC files were decoded in 16 bits even if 24 bits decoding was enabled in foobar2000?
Yes, I just checked again with an older version of kode54's FDK-AAC packet decoder - only the upper 16 bits were actually used even when converting to 24 bits. I recommend updating to the new version 1.21 of the packet decoder.

enc v1.1.5-9a1c4ee3, dec v1.19
#a-e - poor sound quality at the output (foobar).
Thanks for reporting! I forgot to re-tune some constant for the SBR modes. Will be fixed in the next exhale release. Attached a preview for this particular item (preset d, mod is the new version).

The "Medium"? Is that assigned by dBpoweramp then?
I guess so, exhale certainly doesn't write a "Medium" quality indicator into the xHE-AAC files. The "medium" description does seem to make sense at this bit-rate, though, so not an issue IMHO.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: alter4 on 2021-05-03 15:56:19
Yes, it's the same issue guruboolez and others once reported (https://hydrogenaud.io/index.php?topic=118888.msg984761#msg984761), some unreliable behavior on some Windows systems when using exhale via stdin (e.g. in foobar2000) and in parallel.

Chris

I faced conversion foobar2000 issue several times but considered as Jupiter is not in the right triangle if u understand my humor. BTW looks like real bug somewhere in code.
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-05-04 21:03:55
I can't even guarantee my plugin is outputting the correct bit depth for SBR. FDK-AAC seems to be totally broken if you don't output the default 16 bits rounded.
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2021-05-04 22:55:00
exhale v1.1.5-9a1c4ee3
Built on May 04, 2021, GCC 10.3.0

https://gitlab.com/ecodis/exhale/-/commits/master
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-05-05 04:17:39
Another release. I still can't figure out why 32 bit builds of FDK-AAC are broken and produce bad SBR output.

Edit: Okay, it appears Peter's bitstream parser is handing me bad data.
Title: Re: exhale - Open Source USAC encoder
Post by: capma on 2021-05-05 16:24:12
I see it now showing PS presence. Nice :)
Title: Re: exhale - Open Source USAC encoder
Post by: soundping on 2021-05-05 21:45:58
Same problem with accb67be

foobar2000 1.6.6 beta 6
fdk-aac pack decoder 1.22
Windows 10 build 21370
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-05-05 23:53:20
Are you sure you're even encoding files properly? I literally have no idea how your machine is managing to make the encoders interfere with each other when they're separate processes. Literally, the files you shared with me were just random garbage, not even valid MP4 files.

@kode54 , in AAC Packet Decoder option description for DRC reference level says that disabled is -1. But description of options for libfdk in ffmpeg says that disabled is -2 and auto is -1.
Code: [Select]
-drc_level         <int>        .D..A...... Dynamic Range Control: reference level, quantized to 0.25dB steps where [0] is 0dB and [127] is -31.75dB, -1 for auto, and -2 for disabled (from -2 to 127) (default -1)
Is description in AAC Packet Decoder correct?
Well, the headers in the library say the valid range of options is 40...127, 96 (-24 dB) is the default, and -1 is disabled.

Also, I found the decode error that was causing me to fail validation for some files. It seems foobar is dropping the first packet for those files, so I'm not even decoding it.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-05-06 00:51:51
I faced conversion foobar2000 issue several times but considered as Jupiter is not in the right triangle if u understand my humor.
Same problem with accb67be
I haven't fixed that issue yet, you'll have to rely on the last executable that worked for you. Like I mentioned before (I think), I do not observe this issue on my own PC when e.g. converting my FLACs to xHE-AAC, which makes it hard to debug. It really seems to depend on the hardware/driver/software configuration.

But can you two check if things get any better if you disable the metadata transfer during conversion? See this old Wiki entry (https://gitlab.com/ecodis/exhale/-/wikis/faq#i-get-corrupted-files-when-encoding-using-exhale-via-foobar2000-why) for instructions.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-05-06 01:27:46
How is this even an issue? The executables shouldn't be interacting with each other.
Title: Re: exhale - Open Source USAC encoder
Post by: soundping on 2021-05-06 01:52:05
I have an AMD Ryzen 9 3900X 12-core
32 GB ram at 3200 MHz
ASUS ROG Strix B450-F
970 EVO Plus SSD 1TB - M.2 NVMe
That's the hardware I'm working with.

The encoder set 108kbps / Preset g
Processing: None.
Other: When finished:
* Transfer tags and attached pictures.

Flac and Opus files no problem.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-05-06 21:21:17
Can you please try again with the latest commit (https://gitlab.com/ecodis/exhale/-/commit/aaf8b0aa) to exhale's Git repository? That version tries to stabilize the WAVE reading routine for some users and also includes a very minor fix for SBR encoding of very low-level signals.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2021-05-06 21:38:40
Intel compiles of exhale-V1.1.5-aaf8b0aa:

www.rarewares.org/files/aac/exhale-V1.1.5-aaf8b0aa_x64.zip (http://www.rarewares.org/files/aac/exhale-V1.1.5-aaf8b0aa_x64.zip)

www.rarewares.org/files/aac/exhale-V1.1.5-aaf8b0aa_x86.zip (http://www.rarewares.org/files/aac/exhale-V1.1.5-aaf8b0aa_x86.zip)
Title: Re: exhale - Open Source USAC encoder
Post by: soundping on 2021-05-06 22:01:00
Success!

John's compile.
exhale-V1.1.5-aaf8b0aa works %100.
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-05-07 00:29:52
It also works on Linux (ARMV7L).
Title: Re: exhale - Open Source USAC encoder
Post by: bittuvns on 2021-05-07 05:01:57
I need some help. I am using exhale in foobar for converting WAV & FLAC into m4a but my converted files dont have any sound and it shows as corrupted file or unsupported format in foobar(i am using latest version of foobar & exhale). Can anyone please help me with guide of using exhale in foobar or any other method which is easy to follow? I followed official guidelines but they are unable to help me.
Title: Re: exhale - Open Source USAC encoder
Post by: Brazil2 on 2021-05-07 09:26:52
my converted files dont have any sound and it shows as corrupted file or unsupported format in foobar
With foobar2000 you must use this specific decoder component:
https://www.foobar2000.org/components/view/foo_pd_aac
Title: Re: exhale - Open Source USAC encoder
Post by: bittuvns on 2021-05-07 11:26:06
With foobar2000 you must use this specific decoder component:
https://www.foobar2000.org/components/view/foo_pd_aac

Thank you so much.. It worked..
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2021-05-07 12:22:55
exhale v1.1.5-Git-aaf8b0aa
Built on May 07, 2021, GCC 10.3.0

https://gitlab.com/ecodis/exhale
Title: Re: exhale - Open Source USAC encoder
Post by: Gravitator on 2021-05-07 13:28:33
enc v1.1.5-aaf8b0aa, dec v1.22
#2-9 -  in the area of 6.6 khz, the sound balance is damaged. (foobar, win64).
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-05-07 22:46:24
Please everyone update the decoder again. There were some issues I was able to fix, regarding IPF dependency, and some compliance behavior with some SBR output due to briefly changing some defines in libFDK-AAC.
Title: Re: exhale - Open Source USAC encoder
Post by: sveakul on 2021-05-08 06:41:01
Please everyone update the decoder again. There were some issues I was able to fix, regarding IPF dependency, and some compliance behavior with some SBR output due to briefly changing some defines in libFDK-AAC.
Thanks kode54 for your continued efforts/expertise on this needed plugin.
Title: Re: exhale - Open Source USAC encoder
Post by: Gravitator on 2021-05-08 07:48:54
enc v1.1.5-aaf8b0aa, dec v1.23
The old man does not give up!  :P
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-05-08 12:38:24
Thanks, but can you briefly explain what you think is wrong on that sample, as in your previous posts? That would save me some time.

Regarding the chirp: that's actually a safety net kicking in, which only happens on noise-free test tone signals like sine sweeps. I converted your 24-bit FLAC to 16 bits/sample with a bit of dither, and the drop-out seems to disappear. So nothing to worry about.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: Gravitator on 2021-05-08 13:44:14
Lines_chord_loop_Gmin - fdk-aac tries to isolate the unpleasant quantization noise at the output at high frequencies (merit of he-v2). xHE allows dirt to pass through.
Chirp - 24bit to 16bit + dithering helped! Can you recommend all 24bits on an automatic basis to be subjected to this procedure?

Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-05-08 17:30:41
No, you don't need to down-convert your 24-bit music to 16-bit before encoding with exhale. As I said, this only affects test signals. Specifically, it affects recordings of isolated loud tones where the lower-frequency neighboring spectrum is at least ~90 dB quieter. That usually doesn't happen in natural audio, only in synthetic test signals.

Regarding Lines_chord_loop, that's a design choice I made (to improve coding of transients), not a bug. But I noticed that your sample, which is a mono-in-stereo signal, uses a bit-rate much lower than the target rate, and this kind of undercoding also happens with the higher-rate SBR presets and, in that magnitude, was unintended. So I improved exhale's behavior (https://gitlab.com/ecodis/exhale/-/commit/08ac873c) on such corner-case audio files. Regular stereo music should not be affected, so no need to re-encode anyone's collection.

Thanks again for reporting!

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2021-05-08 18:46:52
Intel compiles of exhale-V1.1.5-08ac873c:

www.rarewares.org/files/aac/exhale-V1.1.5-08ac873c_x64.zip (http://www.rarewares.org/files/aac/exhale-V1.1.5-08ac873c_x64.zip)

www.rarewares.org/files/aac/exhale-V1.1.5-08ac873c_x86.zip (http://www.rarewares.org/files/aac/exhale-V1.1.5-08ac873c_x86.zip)

:)
Title: Re: exhale - Open Source USAC encoder
Post by: Gravitator on 2021-05-09 06:26:05
When will foobar learn to display version-build number in file details?
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2021-05-09 14:37:52
When will foobar learn to display version-build number in file details?

Take that up with @Peter. Author of foobar2000
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2021-05-09 14:41:09
exhale v1.1.5-Git-08ac873c
Built on May 09, 2021, GCC 10.3.0 & Clang11 builds

A friend wanted a Clang compile so i added it here also.
Title: Re: exhale - Open Source USAC encoder
Post by: Gravitator on 2021-05-09 21:45:54
enc v1.1.5-08ac873c, dec v1.23
#a-g - need tuning at high frequencies.
> Exodus-Blak_13.flac (https://files.videohelp.com/u/227452/Exodus-Blak_13.flac)
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-05-10 03:03:30
When will foobar learn to display version-build number in file details?

Take that up with @Peter. Author of foobar2000
Where would it obtain this information? The files don't appear to be tagged with any such value.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-05-10 11:11:36
exhale.exe -v returns a version string. That could be written as MP4 udta box along with the CVBR preset set in the new Converter GUI for exhale.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: Brazil2 on 2021-05-10 11:16:58
Where would it obtain this information? The files don't appear to be tagged with any such value.
Some programs and applications are tagging this information, look at the attached image.
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2021-05-10 13:57:51
When will foobar learn to display version-build number in file details?

Take that up with @Peter. Author of foobar2000
Where would it obtain this information? The files don't appear to be tagged with any such value.

My fault, thought about fb2ks version........
Title: Re: exhale - Open Source USAC encoder
Post by: IgorC on 2021-05-10 14:21:49
enc v1.1.5-08ac873c, dec v1.23
#a-g - need tuning at high frequencies.
> Exodus-Blak_13.flac (https://files.videohelp.com/u/227452/Exodus-Blak_13.flac)
It's probably not  something to do with tuning. It's how SBR works and this particular sample is just hard for it.
You can try without SBR and see or resample your source to 64 kHz that would push SBR range to higher range only (15-20 kHz) making its impact pretty insignificant and very close to no-SBR mode. 
Title: Re: exhale - Open Source USAC encoder
Post by: Gravitator on 2021-05-10 15:05:04
enc v1.1.5-08ac873c, dec v1.23
Here's another complication.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-05-11 09:37:36
Exodus: Igor is (partially) right. SBR can, in principle, deal with such weird high-frequency sine tones to some extent, but exhale, with its simplified SBR encoder, cannot. Btw, do you actually hear high-frequency artifacts on that sample, or are you looking more at spectrograms?

Vangelis: Issue confirmed, I managed to reduce that effect, but need more time for checks since my fix changes the encoding of many samples when encoding with one of the SBR modes. You seem very experienced at spotting such issues. Are you a codec developer yourself? ;)

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: Gravitator on 2021-05-11 10:45:40
I hear the whistle that after encoding turns into hiss  :o Who else hears?
 I am the developer of the problems :D
Title: Re: exhale - Open Source USAC encoder
Post by: guruboolez on 2021-05-11 11:12:55
After my comparison (https://hydrogenaud.io/index.php?topic=118888.msg996833#msg996833) between SBR and non-NBR settings of Exhale at ~48 and ~64 kbps, here is my bling test comparison at ~80 kbps. 40 samples were tested, divided in four group of 10 samples—the last one being usually much harder for lossy encoders. Bitrate is not fully comparable: exhale d (SBR) is ~74 kbps and exhale 2 is ~80 kbps (and Exhale e is ~86 kbps on my bitrate table (https://docs.google.com/spreadsheets/d/18lGNoBB0ZB2A4SGAw3_z-5L7gzl54MG3D_V7tf2jII8/edit?usp=sharing)).

(https://zupimages.net/up/21/19/gtkm.png) (https://zupimages.net/viewer.php?id=21/19/gtkm.png)

At this bitrate and on these 40 samples SBR and non-SBR settings are on par (3,78 vs 3,72) and statistically tied. The graph also show that SBR is here less reliable than non-SBR: more samples on the top and more samples on the bottom of the graph. With SBR Exhale shines more often than without SBR but seems to have stronger issues as well. It's not something new, SBR is like that…

If I split the whole picture into two separate groups (30 samples of "common" musical samples and a last group of problem samples):
(https://zupimages.net/up/21/19/neea.png) (https://zupimages.net/viewer.php?id=21/19/neea.png)(https://zupimages.net/up/21/19/nyu8.png) (https://zupimages.net/viewer.php?id=21/19/nyu8.png)

Exhale d is not statistically better than exhale 2 on common music samples but is obviously worse on known as problematic samples (due to strong smearing for the most part). Moreover the slight quality bonus that appears with SBR is coming for a good part from the 10 classical samples group:
(https://zupimages.net/up/21/19/3e9g.png) (https://zupimages.net/viewer.php?id=21/19/3e9g.png)

As a conclusion there's no evidence that SBR is of any benefit over non-SBR settings at 80 kbps but it's really clear that SBR harms sound quality on sharp transients (lower time resolution) and that quality is more volatile. SBR might nevertheless bring at this bitrate some quality gain on specific musical genre (classical music, atmospheric, that kind of ~tonal music).

Therefore I won't test SBR vs non-SBR at higher bitrate (eg 96 kbps).




_____

(https://zupimages.net/up/21/19/dqpk.png) (https://zupimages.net/viewer.php?id=21/19/dqpk.png)
(https://zupimages.net/up/21/19/z28p.png) (https://zupimages.net/viewer.php?id=21/19/z28p.png)
Title: Re: exhale - Open Source USAC encoder
Post by: guruboolez on 2021-05-11 12:48:04
Now if I merge my two separate tests (48 & 64 kbps; 80 kbps) I get the following results:

(https://zupimages.net/up/21/19/vloi.png) (https://zupimages.net/viewer.php?id=21/19/vloi.png)
(https://zupimages.net/up/21/19/8mgm.png) (https://zupimages.net/viewer.php?id=21/19/8mgm.png)
(https://zupimages.net/up/21/19/617m.png) (https://zupimages.net/viewer.php?id=21/19/617m.png)


Quality improvements between Exhale c and Exhale d is only +0.2 for a 12.5 kbps bonus. Without SBR the MOS improves by +0.5 between Exhale 1 and 2 for 15 additional kbps. It's clear that SBR struggles to increase quality past ~64 kbps.


Kamedo2 also made a table of test's results (https://hydrogenaud.io/index.php?topic=120936.msg997232#msg997232); the update version looks like this:

Target bitrateBest command lineMOS reported by testers
36kbpsexhale a in.wav out.mp4
48kbpsexhale b in.wav out.mp43.03, guruboolez (https://hydrogenaud.io/index.php?topic=118888.msg996833#msg996833)
60kbpsexhale c in.wav out.mp43.34, Kamedo2 (https://hydrogenaud.io/index.php?topic=120936) 3.52, guruboolez (https://hydrogenaud.io/index.php?topic=118888.msg996833#msg996833)
64kbpsrefalac64 in.wav --rate 32000 -D -b 32 -o in-32kHz.wav && exhale 1 in-32kHz.wav out.mp43.43, Kamedo2 (https://hydrogenaud.io/index.php?topic=120936) 3.05, guruboolez (https://hydrogenaud.io/index.php?topic=118888.msg984385#msg984385)
75kbpsexhale d in.wav out.mp43.72, guruboolez (https://hydrogenaud.io/index.php?topic=118888.msg997431#msg997431)
80kbpsexhale 2 in.wav out.mp43.79, Kamedo2 (https://hydrogenaud.io/index.php?topic=120936) 3.78, guruboolez (https://hydrogenaud.io/index.php?topic=118888.msg997431#msg997431)
85kbpsexhale e in.wav out.mp43.64, Kamedo2 (https://hydrogenaud.io/index.php?topic=120936.0)
96kbpsexhale 3 in.wav out.mp44.15, Kamedo2 (https://hydrogenaud.io/index.php?topic=119861.0) 4.37, IgorC (https://hydrogenaud.io/index.php?topic=118888.msg982749#msg982749)
112kbpsexhale 4 in.wav out.mp4
128kbpsexhale 5 in.wav out.mp44.39, Kamedo2 (https://hydrogenaud.io/index.php?topic=119861.0)
144kbpsexhale 6 in.wav out.mp4
160kbpsexhale 7 in.wav out.mp4
176kbpsexhale 8 in.wav out.mp4
192kbpsexhale 9 in.wav out.mp44.86, IgorC (https://hydrogenaud.io/index.php?topic=120007.0)
At 80 kbps with Exhale 2 Kamedo2 and I share the exact same Mean Opinions Score (3.79 vs 3.78) despite different samples and test settings. SBR MOS are a bit different but not very far (3.64 with Exhale e/85kbps for Kamedo2 and 3.72 with exhale d/74kbps on my side).
Title: Re: exhale - Open Source USAC encoder
Post by: Kamedo2 on 2021-05-11 14:40:24
We may want to remove the 85kbps exhale e, because one can both cut 5kbps and have the better rating, in other words 85kbps exhale e is not a current pareto frontier.

Target bitrateBest command line, based on tests and (when no data exists) anecdotal evidenceMOS reported by testers
36kbpsexhale a in.wav out.mp4
48kbpsexhale b in.wav out.mp43.03, guruboolez (https://hydrogenaud.io/index.php?topic=118888.msg996833#msg996833)
60kbpsexhale c in.wav out.mp43.34, Kamedo2 (https://hydrogenaud.io/index.php?topic=120936) 3.52, guruboolez (https://hydrogenaud.io/index.php?topic=118888.msg996833#msg996833)
64kbpsrefalac64 in.wav --rate 32000 -D -b 32 -o in-32kHz.wav && exhale 1 in-32kHz.wav out.mp43.43, Kamedo2 (https://hydrogenaud.io/index.php?topic=120936) 3.05, guruboolez (https://hydrogenaud.io/index.php?topic=118888.msg984385#msg984385)
75kbpsexhale d in.wav out.mp43.72, guruboolez (https://hydrogenaud.io/index.php?topic=118888.msg997431#msg997431)
80kbpsexhale 2 in.wav out.mp43.79, Kamedo2 (https://hydrogenaud.io/index.php?topic=120936) 3.78, guruboolez (https://hydrogenaud.io/index.php?topic=118888.msg997431#msg997431)
96kbpsexhale 3 in.wav out.mp44.15, Kamedo2 (https://hydrogenaud.io/index.php?topic=119861.0) 4.37, IgorC (https://hydrogenaud.io/index.php?topic=118888.msg982749#msg982749)
112kbpsexhale 4 in.wav out.mp4
128kbpsexhale 5 in.wav out.mp44.39, Kamedo2 (https://hydrogenaud.io/index.php?topic=119861.0)
144kbpsexhale 6 in.wav out.mp4
160kbpsexhale 7 in.wav out.mp4
176kbpsexhale 8 in.wav out.mp4
192kbpsexhale 9 in.wav out.mp44.86, IgorC (https://hydrogenaud.io/index.php?topic=120007.0)
Title: Re: exhale - Open Source USAC encoder
Post by: IgorC on 2021-05-11 19:46:14
Bitrate is not fully comparable: exhale d (SBR) is ~74 kbps and exhale 2 is ~80 kbps (and Exhale e is ~86 kbps on my bitrate table).
Interesting test.  :) 
I guess It wouldn't be bad idea to test both SBR ~74 and ~86 kbps settings and calculate an estimate score (at imaginary ~80 kbps) by averaging both values.
Title: Re: exhale - Open Source USAC encoder
Post by: guruboolez on 2021-05-11 20:32:16
Bitrate is not fully comparable: exhale d (SBR) is ~74 kbps and exhale 2 is ~80 kbps (and Exhale e is ~86 kbps on my bitrate table).
Interesting test.  :) 
I guess It wouldn't be bad idea to test both SBR ~74 and ~86 kbps settings and calculate an estimate score (at imaginary ~80 kbps) by averaging both values.
It's indeed a good but time expensive solution.

Some score/MOS estimation of mine for SBR:

50 kbps to 61 kbps [+11 kbps] = +0.49
61 kbps to 73 kbps [+12 kbps] = +0.20
73 kbps to 85 kbps [+12 kbps] = +0.10…0.15 [estimation]
so 80 kbps => +0.05 to +0.07 = 3.77 to 3.79
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2021-05-13 10:06:40
Intel compiles of exhale-V1.1.5-a327f120 (retune TNS for SBR):

www.rarewares.org/files/aac/exhale-V1.1.5-a327f120_x64.zip (http://www.rarewares.org/files/aac/exhale-V1.1.5-a327f120_x64.zip)

www.rarewares.org/files/aac/exhale-V1.1.5-a327f120_x86.zip (http://www.rarewares.org/files/aac/exhale-V1.1.5-a327f120_x86.zip)

:)
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2021-05-13 15:25:22
exhale v1.1.5-Git-a327f120
Built on May 13, 2021, GCC 10.3.0

https://gitlab.com/ecodis/exhale/-/commits/master
Title: Re: exhale - Open Source USAC encoder
Post by: IgorC on 2021-05-13 16:39:14
Some score/MOS estimation of mine for SBR:

50 kbps to 61 kbps [+11 kbps] = +0.49
61 kbps to 73 kbps [+12 kbps] = +0.20
73 kbps to 85 kbps [+12 kbps] = +0.10…0.15 [estimation]
so 80 kbps => +0.05 to +0.07 = 3.77 to 3.79
I see, means a conclusion is pretty the same:
SBR is useful at 36,48 and maybe 60 kbps bitrates and not higher.

Thanks!
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-05-13 22:28:20
I think the SBR preset d (target rate 72 kbps for stereo) is actually a good intermediate choice between the ~60 kbps of SBR preset c and the ~80 kbps of non-SBR preset 2. As guruboolez's results show, it allows you to save a few kbps with "easier-to-code" musical genres like pop or classical music. On the other hand, if you're listening more to rock or electronic music, you can spend only a few kbps more with preset 2 and get slightly better quality.

Btw, starting at SBR preset c, upsampling the input to 48 kHz may give very slightly better audio quality on transient samples (since SBR starts around 11.6 instead of 11 kHz). Just for the record, I haven't actually tested that myself since my high-frequency hearing isn't what it used to be.

I hear the whistle that after encoding turns into hiss  :o Who else hears?
I am the developer of the problems :D
:) Any further problems to report? I also hear the whistle, but only when I turn up the volume so much that the loudness of the music hurts my ears.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: Gravitator on 2021-05-14 13:22:01
I can hear it at the lowest volume. Is it worth it for us to add a key to expand the high range for SBR?
Title: Re: exhale - Open Source USAC encoder
Post by: IgorC on 2021-05-14 16:09:55
I think the SBR preset d (target rate 72 kbps for stereo) is actually a good intermediate choice between the ~60 kbps of SBR preset c and the ~80 kbps of non-SBR preset 2. As guruboolez's results show, it allows you to save a few kbps with "easier-to-code" musical genres like pop or classical music. On the other hand, if you're listening more to rock or electronic music, you can spend only a few kbps more with preset 2 and get slightly better quality.
Yep, more than fair enough!

Btw, starting at SBR preset c, upsampling the input to 48 kHz may give very slightly better audio quality on transient samples (since SBR starts around 11.6 instead of 11 kHz).
I have unfinished test of older version exhale 1.1.0, SBR, 44.1 vs 48 kHz @ ~ 48 kbps.
48kHz helps a lot actually even  at 48 kbps.
Code: [Select]
	48 kbps , exhale 1.1.0					
exhale noSBR exhale sbr exhale sbr 48 kHz Opus 47.2k MP3 96k MP3 128k
01 Castanets 2.8 1.8 3.2 2.6 2.6 2.8
02 Fatboy 1.3 1.3 1.3 4.2 1.5 3.6
03 EIG 4.1 2.5 2.7 3.6 1.6 2.9
04 Bachpsichord 2.3 2.9 4.5 1.8 2.5 4.5
05 Enola 3 2.9 2.9 2.1 3.1 4.5
06 Trumpet 3.2 3.5 3.2 3.9 2.7 2.9
07 applaud
08 Velvet
09 Linchpin
10 spill_the_blood

Kamedo2’s samples:
11 final fantasy bach
12 A train Jazz
13 Big Yellow
13 Fatboy
14 Floor Essence
15 Macabre Orchestral
16 mybloodrusts guitar
17 quizas
18 VelvetRealm
19 Amefuribana Pops
20 Trust Gospel
21 Waiting
22 Experiencia
23  Heart to Heart
24 Tom's Dinar
26 French Speech
27 undelete

MOS (Mean Opinion Score) 2.78 2.48 2.97 3.03 2.33 3.53

min 1.3 1.3 1.3 1.8 1.5 2.8

Another unfinished test on 3-band vs 1-band SBR .  (exhale 1.1.1 vs 1.1.0)
Code: [Select]
	48 kbps SBR	
Exhale 1.1.1 Exhale 1.1.0
01 Castanets 3 3
02 Get Your shirt 4.1 3.8
03 EIG 2.5 2.5
04 Bachpsichord 3.4 3.1
05 Enola
06 Trumpet
07 applaud
08 Velvet
09 Linchpin
10 spill_the_blood
11 female_speech
12 french ad
13 fatboy

MOS (Mean Opinion Score) 3.25 3.10

min 2.5 2.5

Title: Re: exhale - Open Source USAC encoder
Post by: Jurgga on 2021-05-15 19:14:02
EZ CD Audio Converter 9.3.2 now includes

Exhale Extended HE-AAC encoder 1.1.5-a327f120
and
Fraunhofer xHE-AAC encoder 3.5.5

Exhale can be enabled with CTRL+E for testing purposes.

You know what is changed in Exhale. The new Fraunhofer xHE-AAC encoder includes a fix for a bug that affected the audio quality on certain cases.

Is anyone interested performing audio quality tests Exhale vs Fraunhofer xHE-AAC or Fraunhofer FDK AAC vs Fraunhofer IIS AAC vs Apple AAC ? I will give free EZ CD Audio Converter license for testing purposes for those who are interested and have performed listening tests before here on hydrogenaud.io.

* If you consider this message as spam or advertisement please delete this message because it is not my intention *
Title: Re: exhale - Open Source USAC encoder
Post by: guruboolez on 2021-05-15 19:26:15
The last version of Fraunhofer's xHE-AAC changes the bitrate allocation of VBR 0 and VBR 1 mode. See my bitrate table (on the dedicated tab):
https://docs.google.com/spreadsheets/d/18lGNoBB0ZB2A4SGAw3_z-5L7gzl54MG3D_V7tf2jII8/edit?usp=sharing

Other VBR modes looks unchanged.


For the anecdote, I've completed ~70% of my new listening test which compares OPUS to Fraunhofer's xHE-AAC at very low bitrate (translation=I'm interested by a KEY for making more tests in the future  :P )
Title: Re: exhale - Open Source USAC encoder
Post by: soundping on 2021-05-16 14:08:24
I did a quick Dynamic Range test with foobar2000 and EZ CD Audio Converter 9.3.2

The FLAC DR is higher?
Title: Re: exhale - Open Source USAC encoder
Post by: guruboolez on 2021-05-16 14:59:09
The FLAC DR is higher?

DR Meter is a bad tool for measuring dynamic range. Forget it.
In fact, according to your test, FLAC has a lower DR value than all lossy encodings.
Title: Re: exhale - Open Source USAC encoder
Post by: bennetng on 2021-05-16 15:24:51
I did a quick Dynamic Range test with foobar2000 and EZ CD Audio Converter 9.3.2

The FLAC DR is higher?

Convert the attached file to several lossy formats with different settings, this will show how useless the DR meter is.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-05-16 16:53:14
I have unfinished test of older version exhale 1.1.0, SBR, 44.1 vs 48 kHz @ ~ 48 kbps.
48kHz helps a lot actually even  at 48 kbps.
Code: [Select]
	48 kbps , exhale 1.1.0					
...
MOS (Mean Opinion Score) 2.78 2.48 2.97 3.03 2.33 3.53

min 1.3 1.3 1.3 1.8 1.5 2.8
Great, thanks a lot for this info! If you or anyone else ever ends up being bored in the near future, I'd be extremely curious to see this test being completed :)

Regarding the DR discussion: don't know that that "Official DR Value" in the spreadsheet means, but the loudness range in EBU R128 resp. ITU-R BS.1770-4 (https://www.itu.int/rec/R-REC-BS.1770-4-201510-I/en) seems to be one of the most accurate and standardized ways of measuring such information.

Oh, and in case you're wondering: my latest change to the exhale source code shouldn't change exhale's behavior.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2021-05-16 18:19:25
Intel compiles of exhale-V1.1.5-1592b40c:

www.rarewares.org/files/aac/exhale-V1.1.5-1592b40c_x64.zip (http://www.rarewares.org/files/aac/exhale-V1.1.5-1592b40c_x64.zip)

www.rarewares.org/files/aac/exhale-V1.1.5-1592b40c_x86.zip (http://www.rarewares.org/files/aac/exhale-V1.1.5-1592b40c_x86.zip)

:)
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2021-05-16 23:32:59
exhale v1.1.5-Git-1592b40c
Built on May 16, 2021, GCC 10.3.0

https://gitlab.com/ecodis/exhale/-/commits/master
Title: Re: exhale - Open Source USAC encoder
Post by: Gravitator on 2021-05-18 13:21:23
enc v1.1.5-1592b40c, dec v1.23
#a-g - the encoder suppresses one channel out of two.
Title: Re: exhale - Open Source USAC encoder
Post by: bennetng on 2021-05-19 12:02:18
enc v1.1.5-1592b40c, dec v1.23
#a-g - the encoder suppresses one channel out of two.
These signals should not be used to test SBR modes I suppose, the Winamp AAC encoder also cannot encode them correctly when using SBR.
Title: Re: exhale - Open Source USAC encoder
Post by: Gravitator on 2021-05-19 12:50:28
enc v1.1.5-1592b40c, dec v1.23, foobar2000 v1.6.6, win64
#a-g - conversion failed (noSBR is fine).

Title: Re: exhale - Open Source USAC encoder
Post by: bennetng on 2021-05-19 14:28:52
enc v1.1.5-1592b40c, dec v1.23, foobar2000 v1.6.6, win64
#a-g - conversion failed (noSBR is fine).


Same here:
  Conversion failed: Unsupported format or corrupted file (moov box not found)
Title: Re: exhale - Open Source USAC encoder
Post by: IgorC on 2021-05-19 21:31:22
If you or anyone else ever ends up being bored in the near future, I'd be extremely curious to see this test being completed :)
Yep, that will be great. It's difficult to concentrate for me on something in this moment. Hopefully Kamedo2 , Guru or somebody else can run some tests.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-05-20 00:00:46
enc v1.1.5-1592b40c, dec v1.23, foobar2000 v1.6.6, win64
#a-g - conversion failed (noSBR is fine).
Thanks, bug identified, will be fixed on the weekend.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: Jurgga on 2021-05-20 12:32:44
Exhale 1.1.5-1592b40c for EZ CD Audio Converter

Put DLLs ("x86\" for 32-bit "x64\" for 64bit) to "C:\Program Files\EZ CD Audio Converter\"

Press "Ctrl+E" to enable in Exhale (for testing purposes ::)) in EZ CD Audio Converter

Good news - "Exhale 1.1.5-1592b40c for EZ CD Audio Converter" successfully passed the xHE-AAC™ encoder compliancy tests developed by Fraunhofer.
Title: Re: exhale - Open Source USAC encoder
Post by: prajaybasu on 2021-05-21 15:14:14
Exhale 1.1.5-1592b40c for EZ CD Audio Converter

Put DLLs ("x86\" for 32-bit "x64\" for 64bit) to "C:\Program Files\EZ CD Audio Converter\"

Press "Ctrl+E" to enable in Exhale (for testing purposes ::)) in EZ CD Audio Converter

I believe there is a bug - EZ CD does not offer the option of e-g for the highest bitrate SBR mode.
Title: Re: exhale - Open Source USAC encoder
Post by: guruboolez on 2021-05-21 15:34:11
Exhale 1.1.5-1592b40c for EZ CD Audio Converter

Put DLLs ("x86\" for 32-bit "x64\" for 64bit) to "C:\Program Files\EZ CD Audio Converter\"

Press "Ctrl+E" to enable in Exhale (for testing purposes ::)) in EZ CD Audio Converter

I believe there is a bug - EZ CD does not offer the option of e-g for the highest bitrate SBR mode.
I don't think it's a bug. You can find the same behavior with AAC encoders like FHG or formerly FDK: some presets are discarded and EZ only offers the presumably best choice for each targeted bitrate. In this case, SBR is enabled by default for 48…72 kbps but for higher bitrates the core encoder is set by default. I think it's done on purpose to make the usage easier for end-users (in my opinion it's a good choice).
Title: Re: exhale - Open Source USAC encoder
Post by: prajaybasu on 2021-05-21 17:22:08
Exhale 1.1.5-1592b40c for EZ CD Audio Converter

Put DLLs ("x86\" for 32-bit "x64\" for 64bit) to "C:\Program Files\EZ CD Audio Converter\"

Press "Ctrl+E" to enable in Exhale (for testing purposes ::)) in EZ CD Audio Converter

I believe there is a bug - EZ CD does not offer the option of e-g for the highest bitrate SBR mode.
I don't think it's a bug. You can find the same behavior with AAC encoders like FHG or formerly FDK: some presets are discarded and EZ only offers the presumably best choice for each targeted bitrate. In this case, SBR is enabled by default for 48…72 kbps but for higher bitrates the core encoder is set by default. I think it's done on purpose to make the usage easier for end-users (in my opinion it's a good choice).

If there is a hidden option for a new encoder requiring a special key combination to enable, I think all options should be available for it. At least until there are public ABX tests to confirm that those options are the best choice. In my case I would like to test the various options for particular genres in my library.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-05-22 17:19:23
In my case I would like to test the various options for particular genres in my library.
You can still use e.g. foobar2000 for that, see exhale's Readme or the Wiki mentioned in the first post of this thread. As a personal remark, I agree with guruboolez that the simplified configuration provided in the EZ CD Audio Converter software is well chosen.

I just finished a new exhale 1.1.6 release candidate (commit e38b9a3 (https://gitlab.com/ecodis/exhale/-/commit/e38b9a3)) which, hopefully, fixes both the "conversion failed" and "missing 6-kHz tone" issues reported by Gravitator (thanks again!). As usual, let me know if there are any issues with this version. I'll turn this into the final release next weekend.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2021-05-22 17:31:36
Intel compiles of exhale-V1.1.6-RC1-e38b9a3d:

www.rarewares.org/files/aac/exhale-V1.1.6-RC1-e38b9a3d_x64.zip (http://www.rarewares.org/files/aac/exhale-V1.1.6-RC1-e38b9a3d_x64.zip)

www.rarewares.org/files/aac/exhale-V1.1.6-RC1-e38b9a3d_x86.zip (http://www.rarewares.org/files/aac/exhale-V1.1.6-RC1-e38b9a3d_x86.zip)

:)
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-05-23 00:08:32
macOS Universal compile for x86_64 and arm64, of exhale-v1.1.6-RC1-e38b9a3:
Title: Re: exhale - Open Source USAC encoder
Post by: Gravitator on 2021-05-26 14:40:50
Why does any SBR mode cut channel frequencies up to 13 kHz with stereo input 32kHz?
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-05-26 15:14:11
Are you referring to Exhale or EZ CD Audio converter?

EZ CD Audio converter uses SBR 8:3 in VBR and 2:1 in CBR at low bitrates. Perhaps the author of the program can explain the reason for this choice.
Title: Re: exhale - Open Source USAC encoder
Post by: Gravitator on 2021-05-26 16:34:14
celona, the name of the topic. For closed Fraunhofer needs a separate topic (avoid confusion).
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-05-26 23:16:13
This is a limitation of exhale's SBR encoder, it can only do SBR encoding with a cutoff frequency of around 38% of the sampling rate. But for the bitrates supported by exhale, I don't think that SBR encoding at 32 kHz sounds better than encoding at 44.1 or 48 kHz, anyway, mostly because pre-echo artifacts become more audible (the temporal resolution is really low then).

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: Gravitator on 2021-05-27 08:16:04
don't think that SBR encoding at 32 kHz sounds better than encoding at 44.1 or 48 kHz, anyway, mostly because pre-echo artifacts become more audible (the temporal resolution is really low then).
Does this rule not work for mode #0 with 32 kHz limit?
Title: Re: exhale - Open Source USAC encoder
Post by: Gravitator on 2021-05-27 08:26:09
enc v1.1.6-RC1-e38b9a3d, dec v1.23, win64
#a - а cricket appears in the background for the second second.

Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-05-28 22:47:48
Does this rule not work for mode #0 with 32 kHz limit?
Correct, for the non-SBR modes, mode 0 sounds better at 32 kHz than at higher sampling rates. For SBR modes, it's different because the codec internally halves the sampling rate.

Regarding the "cricket": I can't hear it, but I think I know what you mean. Does it go away when you downsample the input file to 44.1 kHz before encoding with mode a? 48 kHz might be a bit too much for the lowest SBR mode on some audio.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: Gravitator on 2021-05-28 23:53:33
There is an improvement when downgraded to 44.1 kHz! I hear a cricket on the speakers with weak bass.
#a - a crunch appears.
Title: Re: exhale - Open Source USAC encoder
Post by: Gravitator on 2021-05-28 23:56:09
Will there be an upgrade from PS for low bitrate? The synthesis of high frequency recovery is very poor.
Title: Re: exhale - Open Source USAC encoder
Post by: Gravitator on 2021-05-28 23:58:37
#a-g - the tall ones mutate into dirt.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-05-29 23:54:49
The 'Guano Apes' sample is very similar to the 'Vangelis' sample you reported a few weeks back, and I verified that exhale 1.1.6 already sounds much better than, e.g., exhale 1.1.4 on that kind of content.

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

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

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: Gravitator on 2021-05-30 12:51:31
The 'Sandra' sample is yet another sample with some constant high-frequency tone, and as I said previously, exhale's SBR encoder can't deal with such weird content (those tones actually have no musical meaning, they are interference in the original recordings which shouldn't really be there in the first place).
Chris
Just remove such complex high frequencies or reduce echo? The graph shows how the straight line becomes stepped.

Does the encoder have tools for analyzing and restoring stereo panoramas? An additional echo moves the sound from the center to the sides.
I will not implement a parametric stereo or a better (enhanced) SBR into exhale
Chris
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2021-05-30 18:23:53
Intel compiles of exhale-V1.1.6-RC2-b11042a0:

www.rarewares.org/files/aac/exhale-V1.1.6-RC2-b11042a0_x64.zip (http://www.rarewares.org/files/aac/exhale-V1.1.6-RC2-b11042a0_x64.zip)

www.rarewares.org/files/aac/exhale-V1.1.6-RC2-b11042a0_x86.zip (http://www.rarewares.org/files/aac/exhale-V1.1.6-RC2-b11042a0_x86.zip)

:)
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-05-31 10:08:05
Intel compiles of exhale-V1.1.6-RC2-b11042a0:
That's actually the final 1.1.6 release of exhale, I just tagged it.

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

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2021-05-31 11:12:39
Intel compiles of exhale-V1.1.6-RC2-b11042a0:
That's actually the final 1.1.6 release of exhale, I just tagged it.

Chris
OK, I'll update Rarewares shortly.

Edit: Updated. :)
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2021-05-31 19:03:13
exhale v1.1.6-b11042a0 {Stable}
Built on May 31, 2021, GCC 10.3.0

https://gitlab.com/ecodis/exhale/-/releases
Title: Re: exhale - Open Source USAC encoder
Post by: IgorC on 2021-06-01 16:00:50
Intel compiles of exhale-V1.1.6-RC2-b11042a0:
That's actually the final 1.1.6 release of exhale, I just tagged it.

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

https://gitlab.com/ecodis/exhale/-/releases
v1.1.6
Title: Re: exhale - Open Source USAC encoder
Post by: wyup on 2021-06-01 17:14:15
Chris, what DR information does xHE-ACC store on the files and how could your foobar2000 decoder component read these tags and apply them?
I think I read the compressor sort of peak limits or apply -0.01 dBFS maximization. How does foobar then find different peaks per file when ReplayGain scanning?
Title: Re: exhale - Open Source USAC encoder
Post by: Jurgga on 2021-06-02 08:41:32
Exhale 1.1.6 updated to EZ CD Audio Converter 9.3.2 installer (download again from https://www.poikosoft.com (https://www.poikosoft.com) and reinstall to get it)

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

Exhale is not enabled by default in EZ CD Audio Converter (there's another default xHE-AAC™ encoder). Exhale can be enabled with the CTRL+F shortcut for testing purposes
Title: Re: exhale - Open Source USAC encoder
Post by: Jurgga on 2021-06-02 18:43:54

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


CTRL+E that is (my typo)
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-06-04 00:14:50
Chris, what DR information does xHE-ACC store on the files and how could your foobar2000 decoder component read these tags and apply them?
I think I read the compressor sort of peak limits or apply -0.01 dBFS maximization. How does foobar then find different peaks per file when ReplayGain scanning?
exhale stores track loudness and sample peak (but not true peak) value data into xHE-AAC files during encoding (as MPEG-D LoudnessInfo data, not traditional ReplayGain tags), measured on the original input PCM data. Note that the FDK-AAC packet decoder is (or, rather, was (https://hydrogenaud.io/index.php?topic=121067.0)) developed by kode54, not myself, and IIRC, he disabled the peak limiter recently.

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

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-06-04 02:06:11
FDK packet decoder is on life support, it will get emergency fixes with a few days of reporting if necessary, but I don't expect to do that loudnessinfo data support myself. Especially since that's outside the scope of a packet decoder. That's a feature that Peter will have to look into supporting in the MP4 input itself.

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

A scanner which applies values to those tags would also need to flag to the decoder to somehow disable all normalization and peak limiting as well, which there currently is no flag for.
Title: Re: exhale - Open Source USAC encoder
Post by: guruboolez on 2021-06-05 20:48:56
I made a cross comparison of three tests I made these last months with Exhale :


(https://zupimages.net/up/21/22/d4nv.png) (https://zupimages.net/viewer.php?id=21/22/d4nv.png)


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

A comparison to other competitors is joined as attached picture (and opened to debate in this topic (https://hydrogenaud.io/index.php?topic=121104.msg998719#msg998719)).

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

Edit: Kamedo2, in his recent blind listening test (https://hydrogenaud.io/index.php?topic=120936.0), tended to prefer exhale's non-SBR mode 2 at ~80 kbps on his sample set, which contains many hard-to-code samples.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: Jpt on 2021-06-26 23:25:56
Hello Kode54 (or other ?)

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

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

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

For pc (win + x64) all is right with your last driver & foobar (pc)
Regards,
Title: Re: exhale - Open Source USAC encoder
Post by: o-l-a-v on 2021-06-27 12:53:07
Hello Kode54 (or other ?)

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

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

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

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

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


I remember I could play Opus with GMMP before I got an Android version that supported Opus natively. So if any player is able to play xhe-aac on older Android versions, GMMP would be a good bet IMO. :)
Title: Re: exhale - Open Source USAC encoder
Post by: soundping on 2021-06-27 15:45:23
@Jpt @o-l-a-v
Soon you'll be able to run GoneMAD Music Player in Win11.

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

Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-06-27 22:49:55
FFmpeg only supports xHE-AAC if you link in libfdk-aac, and it doesn't take over support for the AAC decoding from the built-in decoder unless it's explicitly requested, so it will still report the files as unsupported.
Title: Re: exhale - Open Source USAC encoder
Post by: Jpt on 2021-06-29 01:46:47
Hi alls,
In first many thank's for your response & added info for others users.
Gonemad runs natively in Android 5.0or more, For kitkat only versions <= to 2.15 is possible to install (Cf: see Download section).
I check it, and him NOT read xHE (sigh) but read the AAC v2+SBR+PS, and for info my others players read so this format.

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

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

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

B.regards




Title: Re: exhale - Open Source USAC encoder
Post by: guruboolez on 2021-06-29 08:55:11
For contacting the author; http://gonemadmusicplayer.blogspot.com/p/contact.html
Title: Re: exhale - Open Source USAC encoder
Post by: nu774 on 2021-06-29 12:03:14
I don't think GMMP can support xHE-AAC with libfdk-aac:
https://hydrogenaud.io/index.php?topic=118888.msg985925#msg985925
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2021-06-29 12:15:57
exhale v1.1.6-Git-057bb87e
Built on June 29, 2021, GCC 10.3.0

https://gitlab.com/ecodis/exhale/-/commits/master
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-06-30 03:05:55
I don't think GMMP can support xHE-AAC with libfdk-aac:
https://hydrogenaud.io/index.php?topic=118888.msg985925#msg985925
Do what I do, and link libFDK-AAC directly, and not give a shit about licensing or patents until the jackboots are pressed directly to my throat.
Title: Re: exhale - Open Source USAC encoder
Post by: Jpt on 2021-06-30 03:06:59
I don't think GMMP can support xHE-AAC with libfdk-aac:
https://hydrogenaud.io/index.php?topic=118888.msg985925#msg985925

Many's thank's from this link.
Okay, it's dead (sigh)

@Grubolez:  It's commercial software, i think users not wanted buy one other player only for read one particular format.
But thank's so for this idea
Title: Re: exhale - Open Source USAC encoder
Post by: Jpt on 2021-06-30 03:12:52
deleted
Title: Re: exhale - Open Source USAC encoder
Post by: Jpt on 2021-06-30 03:14:07
I don't think GMMP can support xHE-AAC with libfdk-aac:
https://hydrogenaud.io/index.php?topic=118888.msg985925#msg985925
Do what I do, and link libFDK-AAC directly, and not give a shit about licensing or patents until the jackboots are pressed directly to my throat.

Here is for linux if i understand
Maybe open one dedicated topic for users helps to make this ?
Title: Re: exhale - Open Source USAC encoder
Post by: multimaxfm on 2021-07-10 06:54:31
Hi, everyone! Tried coding xHE with poikosoft - WOW. At low bitrate - so nice results in compare with old HE.
I want to test EXHALE with  Live Streaming! But seems that codec have no support stdout... Any possibilities to add it? That codec would be very interesting for low bitrate live streaming. Wanna test it on my radio stream.
Seems that it is able to read from stdin (required to accept live audio data) but it does not yet have the ability to write the encoded data to stdout (required to send it to a server).  Please, Please! add stdout =)
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-07-10 10:01:44
See the last part of www.ecodis.de/exhale/release.htm for a brief explanation why exhale currently doesn't support stdout.

I have no experience with live encoding. Can you summarize your workflow (from microphone to streaming server), i.e. your software toolchain when you do live streaming e.g. using HE-AAC?

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: nu774 on 2021-07-10 16:16:04
I think USAC is not very well suited for MPEG-DASH or HLS.
Basically, each fragment/segment has to start with key frame in these formats. Since most audio codecs don't have a concept of key frames, MPEG-DASH multiplexers usually have to take only video track into account for fragmentation.
However, USAC also requires that fragments start with IPF. This complicates things... and it should be possible only when video/audio encoder are tightly coupled, and can emit key frames in synchronized manner.

As for RTP based streaming, I think it should be possible with MP4A-LATM RTP mapping defined in rfc6416.
However, I guess virtually nothing supports USAC in MP4A-LATM in RTP, currently.

As for supporting stdout output, I think LATM is the only viable option for exhale.
Title: Re: exhale - Open Source USAC encoder
Post by: multimaxfm on 2021-07-10 17:37:53
I have no experience with live encoding. Can you summarize your workflow (from microphone to streaming server), i.e. your software toolchain when you do live streaming e.g. using HE-AAC?
i want to try exhale with Breakaway One audio processor (dynamic processor for radiostations and streaming), it can support custom encoders with external exe file, but encoder must support stdin stdout like other encoders do (opusenc.exe, twolame.exe, oggenc2.exe, flac.exe, lame.exe) It would be very interesting to test this codec on the radio stream with proper audio processing before coding (look ahead limiting for example).
radiostations typicaly are not using RTP for internet broadcasting... they are use icecast\shoutcast stream type.

p.s. i wrote to the author on Breakaway (Leif Claesson). He probably can add exhale for testing purposes, but codec should support things that i wrote above. http://www.breakawayone.com/downloads
Title: Re: exhale - Open Source USAC encoder
Post by: multimaxfm on 2021-07-10 20:29:56
Can you summarize your workflow (from microphone to streaming server), i.e. your software toolchain when you do live streaming e.g. using HE-AAC?
well.. BaOne like Edcast, Butt and other streaming software (BaOne is also audio processor) just pucks up mixed signal (ready onair audio, for example mix of music and microphone, like you can do with any external mixer console or cheap audio interface with loopback feature like audient evo4) , encode that audio with selected codec and bitrate and stream to icecast\shoutcast server. that's all
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-07-11 12:00:39
I think USAC is not very well suited for MPEG-DASH or HLS.
What makes you think that? One of the primary use cases for xHE-AAC is adaptive streaming, see e.g. https://www.iis.fraunhofer.de/en/ff/amm/broadcast-streaming/xheaac.html and Netflix's use of xHE-AAC.

By the way, when the audio is at 48 kHz, it's possible to perfectly align the xHE-AAC I-frames (IPFs) with those of modern video codecs, which typically use an I-frame every N pictures, where N is an integer multiple of a power of two. For example, if the video is at 50 fps and uses I-frames every 96 pictures (i.e. every 1.92 seconds), then exhale can use an IPF every 45 audio frames. Similarly, if the video is at 60 fps and has an I-frame every 64 or 128 pictures (i.e. every 1.067 or 2.133 seconds), then exhale can write an IPF every 25 or 50 audio frames.

The most important question is which container format the streaming server (Icecast or Shoutcast, I guess) expects from the compressed audio data written to stdout. Is it LATM? (Update: OK, based on this product specification page (https://www.indexcom.com/products/encoder/legacy/specifications/) it seems that ADTS is the container format of choice for Icecast/Shoutcast. Can anyone confirm this?) I thought that's deprecated and fragmented MP4FF should be used. Fraunhofer's web page linked to above probably contains more detailed guidelines, but I haven't read everything there yet.

multimaxfm, can you point me to a manual describing exactly what container format your streaming software of choice expects? Or asked differently: how do you configure your existing HE-AAC encoder executable so that it writes the correctly formatted AAC audio data to stdout? Or does your streaming software already support encoding to HE-AAC out of the box?

Edit: I found this DIY article (https://www.streamingmediaglobal.com/Articles/Editorial/Featured-Articles/DIY-Live-Audio-Streaming-Using-Icecast-with-FFmpeg-125665.aspx), which describes how to use FFmpeg to encode a microphone (or line) input to stdout for subsequent live streaming through an Icecast server:
(http://dzceab466r34n.cloudfront.net/Images/ArticleImages/InlineImages/116534-Icecast-FFmpeg-Workflow-ORG.png)
So it seems that everything would become easier if someone integrated exhale or some other xHE-AAC encoder into FFmpeg. I don't have time to do that myself, though.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: multimaxfm on 2021-07-11 14:03:18
how do you configure your existing HE-AAC encoder executable so that it writes the correctly formatted AAC audio data to stdout? Or does your streaming software already support encoding to HE-AAC out of the box?
Here is an example how mp3 lame codec do that thing: "lame.exe -r -s 44100 --alt-preset cbr 128 -q 0 -x - - "

They have documented that function:
LAME 32bits version 3.100 (http://lame.sf.net)
usage: lame.exe [options] <infile> [outfile]
<infile> and/or <outfile> can be "-", which means stdin/stdout.


Other encoders do work almost the same way:
That what i use for aac he encoding: "enc_aacPlus.exe - - --br 64000 --he --pns --silent --rawpcm 48000 2 16"
And Opus Codec also can do this: "opusenc.exe --quiet --bitrate 80.000 --raw --raw-bits 16 --raw-rate 48000 --raw-chan 2 - -"
p.s. All of those codecs accept 16-bit stereo from stdin.

Title: Re: exhale - Open Source USAC encoder
Post by: nu774 on 2021-07-11 14:26:47
What makes you think that? One of the primary use cases for xHE-AAC is adaptive streaming, see e.g. https://www.iis.fraunhofer.de/en/ff/amm/broadcast-streaming/xheaac.html and Netflix's use of xHE-AAC.
As I've said, xHE-AAC requires IPFs exactly aligned to key frames of video track for fragmentation to work.
Of course I'm not saying it's impossible, but it is still a requirement, and needs specially crafted pipelines not necessary for other audio codecs.
For example, current ffmpeg implementation only takes care of key frames in video track when making fragments in fMP4 (even though it does follow sync samples of audio track when seeking). Nor it does provide a way to align key frames of video / audio tracks.
Title: Re: exhale - Open Source USAC encoder
Post by: nu774 on 2021-07-12 00:15:26
I reconsidered about this, and well, I noticed I was taking things unnecessarily difficult.
I was under an impression that key frame interval of video is not generally static, so I thought dynamic insertion of IPFs on USAC side is necessary to make them in sync.
Indeed, --keyint of x264/x264 usually doesn't make key frame interval static, unless key frame insertion on scene changes is completely disabled.
However I found that ffmpeg supports -force_key_frames option exactly for this.
If key frame interval of video is static, things are much simpler. We just need to pick appropriate intervals for video/audio, and it's done.


Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-07-12 10:00:27
Exactly. It shouldn't be a problem when the video encoder adds additional key frames, e.g. at scene cuts as you say, as long as key frames are forced at a fixed periodic interval which the audio encoder (here, exhale) can synchronize with.

By the way, if you want to play around with the independency frame interval (i.e. equivalent of the key frame interval in video coding) that exhale uses, you can use the following undocumented "expert" command-line since version 1.1.6:

exhale.exe # s 42 (https://en.wikipedia.org/wiki/Phrases_from_The_Hitchhiker%27s_Guide_to_the_Galaxy#Answer_to_the_Ultimate_Question_of_Life,_the_Universe,_and_Everything_(42)) input.wav output.m4a

where # is the usual CVBR mode and 42 (https://en.wikipedia.org/wiki/Phrases_from_The_Hitchhiker%27s_Guide_to_the_Galaxy#Answer_to_the_Ultimate_Question_of_Life,_the_Universe,_and_Everything_(42)) is the independency frame interval in number of frames (values between 10 and 99 are allowed). Note that the IPF interval is exactly twice the independency frame interval in exhale.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: multimaxfm on 2021-07-12 17:33:46
So it seems that everything would become easier if someone integrated exhale or some other xHE-AAC encoder into FFmpeg. I don't have time to do that myself, though.
i don't think that ffmpeg is popular for radio broadcast streaming... so it is no easy to make pipeline stdou in exhale?
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-07-12 21:36:53
The last time I looked at Exhale, the command line tool, I observed that it isn't really suited to streaming input or output. The encoder library it includes and uses internally may be suited for such, though.

The command line tool seeks around files, and also hand constructs the MP4 container specific to the files it encodes, and again uses seeking to fix up header fields after it finishes encoding.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-07-12 23:18:29
Correct, and I don't see any way around this approach. Writing some data to stdout is easy. Writing fully standard compliant non-MP4 xHE-AAC data to stdout in a way which can be read and played by all xHE-AAC capable decoders is hard.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-07-31 00:40:35
OK, in my latest commit (https://gitlab.com/ecodis/exhale/-/commit/e72c4b1d) to exhale's repository I added

- a minor SBR related fix for 22050 Hz input sampling rate (not recommended to use exhale that way, though, use an input sampling rate of 44.1 or 48 kHz for best possible audio quality) and
- the code necessary for writing the xHE-AAC data to stdout (inside a LATM/LOAS container, which aside from fragmented MP4FF is the only allowed format for streaming applications AFAIK).

The stdout capability, however, is still disabled by default since loudness leveling is missing,* only SBR and stereo coding is supported that way, and I have absolutely no means to test the generated streams for correctness. If you have a software player supporting xHE-AAC inside LATM/LOAS, please let me know.

If you want to test the stdout stuff, compile exhale with #define ENABLE_STDOUT_LOAS 1 set at the top of file src/app/exhaleApp.cpp (around line 76, or send me a PM for assistance), and use the following command-line:

exhale.exe a s 42 input.wav -

where 'a' is any SBR preset (a - g), '42' is the I-frame interval as described in my previous post (https://hydrogenaud.io/index.php?topic=118888.msg1000637#msg1000637), and '-' signals writing to stdout instead of a file. Under Windows you can append
> output.bin (with a space before the >) to save the result to a file. Also, removing the input.wav from the command-line will trigger reading of the WAVE PCM data from stdin.

* Edit: automatic loudness leveling of the input to -23 LUFS in case of writing to stdout has been added now in a follow-up commit (https://gitlab.com/ecodis/exhale/-/commit/9d500c64).
Chris
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2021-07-31 06:35:57
exhale v1.1.6-Git-e72c4b1d-2021-07-31
Built on July 31, 2021, GCC 10.3.0

https://gitlab.com/ecodis/exhale/-/commits/master
Title: Re: exhale - Open Source USAC encoder
Post by: soundping on 2021-07-31 10:33:55
e72c4b1d
SBR  Sounds good.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-07-31 11:12:54
I'm glad to hear that, but please don't post encodings of entire songs longer than 30 seconds. That's a violation of TOS #9 (https://hydrogenaud.io/index.php?topic=3974.msg149482#msg149482) and, since I don't think you're the copyright holder of that song, several national laws.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: kC_ on 2021-07-31 13:54:13
ignore / delete post
fixed issue
Title: Re: exhale - Open Source USAC encoder
Post by: m14u on 2021-07-31 14:05:16
https://www.foobar2000.org/components/view/foo_pd_aac
Title: Re: exhale - Open Source USAC encoder
Post by: kC_ on 2021-07-31 14:08:55
https://www.foobar2000.org/components/view/foo_pd_aac

ah thanks! yeh that sorted it thanks!
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2021-07-31 16:56:00
Compiles now at Rarewares with #define ENABLE_STDOUT_LOAS 1 set.
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-08-01 15:28:21
Compiled for ARM64 Linux.

 exhale.bz2  (125.14 KB)




MOD edit: changed attachment type
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2021-08-02 17:29:14
exhale v1.1.6-Git-9d500c64-2021-07-31
Built on August 02, 2021, GCC 10.3.0

https://gitlab.com/ecodis/exhale/-/commits/master
Title: Re: exhale - Open Source USAC encoder
Post by: Gravitator on 2021-08-09 18:04:50
Yes, removing those extra interference tones before encoding would be an option, yes, but it's not trivial to implement (you would have to analyze the entire song before encoding). But Gravitator, since you seem to be very sensitive to high frequencies: have you considered just using exhale's non-SBR modes or Fraunhofer's encoder?
Chris
I'll try it later :)

enc v1.1.6-9d500c64, dec v1.23, win64
#a - a click appears on the 2nd second.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-08-10 15:57:37
fyi, apparently an xHE-AAC encoder plug-in for FFmpeg will be available soon (don't know if it will be free of charge, though).

The developers, MainConcept and Fraunhofer IIS, will host an introductory Webinar (https://www.brighttalk.com/webcast/19022/502080) on August 18.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-08-10 16:27:47
Thank you. The encoder I purchased has two large limitations: only works with Windows and has only the graphical interface.
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-08-12 18:08:01
Exhale ARM64 for Android (http://https:/www.celona.org/exhale.bz2)
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-08-30 11:50:27
We have a new version to try:
https://gitlab.com/ecodis/exhale
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-08-30 15:54:53
That's the final 1.1.7 release. No functional changes since last month, but since we haven't had a new version for a few months, I decided to make a new one.

To all developers: Please note the changes to exhale's Readme.md (https://gitlab.com/ecodis/exhale/-/blob/master/README.md).

Changes since version 1.1.6 from May 2021:

See also this (https://hydrogenaud.io/index.php?topic=118888.msg1000637#msg1000637) and the following quote of a previous post of mine:

"When the audio is at 48 kHz, it's possible to perfectly align the xHE-AAC I-frames (IPFs) with those of modern video codecs, which typically use an I-frame every N pictures, where N is an integer multiple of a power of two. For example, if the video is at 50 fps and uses I-frames every 96 pictures (i.e. every 1.92 seconds), then exhale can use an IPF every 45 audio frames. Similarly, if the video is at 60 fps and has an I-frame every 64 or 128 pictures (i.e. every 1.067 or 2.133 seconds), then exhale can write an IPF every 25 or 50 audio frames."

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2021-08-30 18:04:48
exhale v1.1.7-acd53a21 (Stable)
Built on August 30, 2021, GCC 10.3.0

https://gitlab.com/ecodis/exhale/-/commits/master

https://gitlab.com/ecodis/exhale/-/releases
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2021-08-31 09:54:05
Updated compiles of exhale-V1.1.7-acd53a21 now at Rarewares.
Title: Re: exhale - Open Source USAC encoder
Post by: alter4 on 2021-09-01 17:22:00
Sorry if this somehow naive question but why is the upper bitrate limited to 192?  Is exhale something by design valuable for low bitrates only?
Title: Re: exhale - Open Source USAC encoder
Post by: griploner on 2021-09-01 22:30:13
So I tried encoding some music files to 40kbps vbr1, very impressed with the quality plays fine on Foobar2000 on my laptop and desktop with correct plugin, copied some files over to my Samsung S10+ plays well with built in music player on CX File Explorer app and Samsung music player app but does not work with Neutron music player or VLC.

What I like is the amount of music we can store now with decent enough audio quality.  Want to try audio books soon with lower bitrates.
Title: Re: exhale - Open Source USAC encoder
Post by: AdamantTurtle on 2021-09-02 09:40:44
I'm loving the exhale encoder; xHE-AAC provides a meaningful improvement in quality at medium quality over Opus. I wanted to thank you Chris for working on it. I've been curious about xHE-AAC for a long time now, given it is older even than Opus, but no encoder was ever available.

I do have one question: are there any plans to make exhale handle files with high bitrate/frequency range (24bit/96KHz?) I'm aware there's no real audible improvement on those over 16/48KHz, but I have some digital albums available only in that capacity, and it would be nice if exhale could automatically step so-called high res audio down to 16/48KHz (or 44.1 KHz) when converting.

Title: Re: exhale - Open Source USAC encoder
Post by: IgorC on 2021-09-02 16:29:56
Sorry if this somehow naive question but why is the upper bitrate limited to 192?  Is exhale something by design valuable for low bitrates only?
Because both AAC and USAC produce high quality at higher rates and the last one doesn't have much of advantage at 128+ kbps area.
(https://csdl-images.computer.org/mags/mu/2013/02/figures/mmu20130200727.gif)
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-09-02 17:03:24
Correct. Also, encoding at very high bit-rates would require more source code to ensure that the resulting files are always fully standard compliant, and I rather spend my time focusing on the lower bit-rates.

are there any plans to make exhale handle files with high bitrate/frequency range (24bit/96KHz?) I'm aware there's no real audible improvement on those over 16/48KHz, but I have some digital albums available only in that capacity, and it would be nice if exhale could automatically step so-called high res audio down to 16/48KHz (or 44.1 KHz) when converting.
exhale happily accepts 24-bit and 32-bit PCM data. You can also encode directly to high sampling rates such as 96 kHz, e.g. using exhale's CVBR modes >a and >4. If you want to explicitly encode to a lower sampling rate and are using foobar2000, see this Wiki entry (https://gitlab.com/ecodis/exhale/-/wikis/faq#how-do-i-configure-foobar2000-for-on-the-fly-resampling-with-exhale) on how to configure for on-the-fly resampling during encoding.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: AdamantTurtle on 2021-09-02 18:57:44
Thank you Chris. I was having conversions fail, and couldn't figure out why. Didn't realize 96 kHz audio couldn't be used as-is with preset 3 (tried both command line and foobar.) I set foobar to resample to 44.1 KHz during conversion, and now my files work without error.
Title: Re: exhale - Open Source USAC encoder
Post by: IgorC on 2021-09-09 16:05:14
This or next month Android 12 will be released.
It brings decoding  support of a new format MPEG-H 3D Audio which is  a successor of xHE-AAC.

Looking at the results, I think it will be a first format which will reach quality of MP3 128 kbps at half of bitrate.
http://ecodis.de/audio/3da_base_results.gif


Not sure if it was offtopic  ::)  but it's related to xHE-AAC somehow. Maybe it's worth already to move to MPEG-H Audio.

Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-09-10 04:24:01
And I doubt that anyone is going to be working on an open source encoder for that for quite a long time.
Title: Re: exhale - Open Source USAC encoder
Post by: Jurgga on 2021-09-10 06:35:19
This or next month Android 12 will be released.
It brings decoding  support of a new format MPEG-H 3D Audio which is  a successor of xHE-AAC.

Looking at the results, I think it will be a first format which will reach quality of MP3 128 kbps at half of bitrate.
http://ecodis.de/audio/3da_base_results.gif


Not sure if it was offtopic  ::)  but it's related to xHE-AAC somehow. Maybe it's worth already to move to MPEG-H Audio.


This or next month Android 12 will be released.
It brings decoding  support of a new format MPEG-H 3D Audio which is  a successor of xHE-AAC.

Looking at the results, I think it will be a first format which will reach quality of MP3 128 kbps at half of bitrate.
http://ecodis.de/audio/3da_base_results.gif


Not sure if it was offtopic  ::)  but it's related to xHE-AAC somehow. Maybe it's worth already to move to MPEG-H Audio.



MPEG-H is for 3D audio. xHE-AAC still is more efficient for music/speech stereo/mono.
Title: Re: exhale - Open Source USAC encoder
Post by: LithosZA on 2021-09-10 07:24:09
Quote
MPEG-H is for 3D audio. xHE-AAC still is more efficient for music/speech stereo/mono.

Have you done listening tests?
Title: Re: exhale - Open Source USAC encoder
Post by: IgorC on 2021-09-10 21:50:59
MPEG-H is for 3D audio. xHE-AAC still is more efficient for music/speech stereo/mono.
Have you familiarized with MPEG-H specs?
Title: Re: exhale - Open Source USAC encoder
Post by: Jurgga on 2021-09-11 06:26:56
Quote
Have you done listening tests?

No. So please ignore my comment on audio quality. I heard MPEG-H is better with multichannel (3D) but it indeed supports channel-based Mono/Stereo as well.

I am going to test an MPEG-H encoder soon. Plan is to include an encoder into EZ CD if everything goes well.
Quote
Have you familiarized with MPEG-H specs?

Yes
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-09-11 12:00:21
MPEG-H is for 3D audio. xHE-AAC still is more efficient for music/speech stereo/mono.
My dissertation (http://www.ecodis.de/about.htm#2017) describes most parts of the "Baseline" MPEG-H Audio standard, especially those which I contributed to. There, I came to the conclusion that, at 48 kbps stereo and above, MPEG-H Audio sounds at least as good as xHE-AAC (sometimes slightly better) but the decoding requires about one third fewer operations. So MPEG-H Audio is slightly more efficient than xHE-AAC at and above 48 kbps stereo (or multichannel equivalent (https://hydrogenaud.io/index.php?topic=120007.msg997612#msg997612)).

I am going to test an MPEG-H encoder soon. Plan is to include an encoder into EZ CD if everything goes well.
That's great to hear! Looking forward to giving it a try!

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: soundping on 2021-09-11 12:38:26
I am going to test an MPEG-H encoder soon. Plan is to include an encoder into EZ CD if everything goes well.
I want candy.  :D
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-09-12 07:19:39
I am going to test an MPEG-H encoder soon. Plan is to include an encoder into EZ CD if everything goes well.

Well, but the problem is that today you still cannot distribute compressed content in these formats because not all operating systems include the decoder, especially Windows, more than a year after the agreement for xHE-AAC, this decoder is still missing in the OS.
Title: Re: exhale - Open Source USAC encoder
Post by: griploner on 2021-09-12 21:13:15
Just wanted to give a big thanks to Chris for this amazing encoder and all the helpers especially Kode54 the admin for the Foobar plugin.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-09-13 10:11:30
You're very welcome. I'm glad you like it, and since the exhale project will most likely get only bugfixes from now on: If anyone encounters strange behavior during encoding which goes beyond "the encoder sounds a bit worse than ... here", please post the details here or open up an issue on https://gitlab.com/ecodis/exhale/-/issues

Fixing as many such issues as possible will make exhale better for everyone. Thanks.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: griploner on 2021-09-15 11:09:19
I just wondered what MPEG-D DRC is? as it is a option in EZCD just found it today whilst encoding some music in 40kbps which is fine for my little old ears,

Thanks again
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-09-16 00:21:47
DRC stands for Dynamic Range Control (https://www.iso.org/obp/ui/#iso:std:iso-iec:23003:-4:ed-2:v1:en), which adds metadata to the encoded xHE-AAC files that can be used for a better listening experience e.g. in a noisy environment. It also includes loudness information similar to ReplayGain that allows to automatically play different music tracks or albums at the same loudness level in compatible players so you don't have to manually adjust the "volume" knob. Exhale calculates and writes the track loudness metadata during encoding, EZ CD Converter might write additional data during encoding, I don't know.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: LithosZA on 2021-09-16 10:33:53
This might be a little off-topic, but has anyone been able to get hold of 'FFmpeg Plugin - xHE-AAC Encoder' from MainConcept?
I registered a while back, but I never received any reply.
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-09-16 16:59:16
I believe the beta is only open to people who have followed their seminar. In any case they have released a beta version for Windows, one for Linux, none for macOS.
Title: Re: exhale - Open Source USAC encoder
Post by: andrew.46 on 2021-09-25 01:32:57
This might be a little off-topic, but has anyone been able to get hold of 'FFmpeg Plugin - xHE-AAC Encoder' from MainConcept?
I registered a while back, but I never received any reply.

Just had a look at this; is this going to be a closed source, commercial 'plugin'?
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-09-25 04:48:27
Probably similar to Fluendo's Oneplay GStreamer codec pack, which is also licenses actual Microsoft Windows Media codecs instead of using reverse engineered solutions from the FFmpeg project. It also licenses all the applicable decoder patents for as many seats as you pay for.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-09-27 11:12:13
I just released a small update to exhale's source code, let's call the result an intermediate version 1.1.7.1. No changes to the audio quality for normal operation (input sampling rate 24...64 kHz), but slight improvements when using SBR coding at 22.05, 88.2, and 96 kHz, and you can now compile exhale in a way which produces more CBR-ish encodings. See this new FAQ Wiki entry (https://gitlab.com/ecodis/exhale/-/wikis/faq#are-further-encoding-options-available-for-experts-and-for-streaming) and the following figure (BA_MORE_CBR is the macro you need to set).

(https://gitlab.com/ecodis/exhale/-/wikis/uploads/eb356e8339f3b12dbe5ebe46a32f2d7b/exhale_more_cbr.png)

Important: CBR coding degrades the audio quality on some samples and is meant primarily for special use cases and research, so its use is generally not recommended!

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-09-27 14:22:41
Exhale 1.7.1 ELF 64-bit LSB pie executable, ARM aarch64 (https://www.celona.org/exhale.bz2)
Title: Re: exhale - Open Source USAC encoder
Post by: m14u on 2021-09-27 17:09:39
Are preset`s "0" and "a" is deprecated now?
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-09-27 17:32:25
They are not recommended (you will now find a warning on the screen) like before. I asked the developer to keep them because there are cases where you don't need to preserve the audio quality, as long as you can understand.

If you need to use them you can do it, but now you will know before that you will get poor quality.
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2021-09-27 21:04:45
exhale v1.1.7.1-f145f63f
Built on September 27, 2021, GCC 10.3.0

Info (https://hydrogenaud.io/index.php?topic=118888.msg1003472#msg1003472)
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2021-09-28 08:17:43
I am away from home until the end of the week, at which time I'll sort out fresh compiles. Sorry for the delay, just unfortunate timing!!
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-10-01 13:01:53
They are not recommended (you will now find a warning on the screen) like before. ... now you will know before that you will get poor quality.
Correct. Sorry for the following legal talk, but I've just been informed that the term xHE-AAC is a trademark term and that I, in order to call exhale an "xHE-AAC encoder", would have to obtain a corresponding xHE-AAC trademark license. Which I can't since exhale does not support encoding at very low bit-rates with sufficient audio quality. Therefore,

please, from now on, call exhale an Extended HE-AAC encoder or a USAC encoder, not an xHE-AAC encoder.

If you are looking for xHE-AAC encoders, you have to this date the following commercially available options which were already discussed in this thread: https://www.poikosoft.com/music-converter and https://www.mainconcept.com/ffmpeg

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2021-10-01 14:42:30
Intel compiles of exhale-V1.1.7.1-f145f63f with BA_MORE_CBR set now at Rarewares.
Title: Re: exhale - Open Source USAC encoder
Post by: Jurgga on 2021-10-01 18:13:34
Please use the 'Extended HE-AAC' rather than USAC (because it's correct)
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-10-02 07:01:24
They are not recommended (you will now find a warning on the screen) like before. ... now you will know before that you will get poor quality.
Correct. Sorry for the following legal talk, but I've just been informed that the term xHE-AAC is a trademark term and that I, in order to call exhale an "xHE-AAC encoder", would have to obtain a corresponding xHE-AAC trademark license. Which I can't since exhale does not support encoding at very low bit-rates with sufficient audio quality. Therefore,

please, from now on, call exhale an Extended HE-AAC encoder or a USAC encoder, not an xHE-AAC encoder.

If you are looking for xHE-AAC encoders, you have to this date the following commercially available options which were already discussed in this thread: https://www.poikosoft.com/music-converter and https://www.mainconcept.com/ffmpeg

Chris
Does this mean that I have to change my macOS audio player to string replace "xHE-AAC" with "USAC", even though I am using Apple's decoder, which calls itself that in the first place? Do I have to somehow figure out how to tell Apple's decoder how to configure itself in all the asinine ways that the trademark application requires, so that I can produce the requisite test vectors? Or does this mean that Apple's decoder is breaking the trademark license by not offering a means of passing said asinine testing requirements?
Title: Re: exhale - Open Source USAC encoder
Post by: Brand on 2021-10-02 09:53:18
Frankly, I think the naming correction is fair, because exhale in fact does not produce the same high quality results at very low bitrates, that you get from an "official" xHE-AAC encoder. I too got confused about it months ago when learning about xHE-AAC, so I think it's a legit concern.
This is not to take anything away from exhale itself, it's great that you're releasing it and I appreciate your efforts.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-10-02 13:00:15
Does this mean that I have to change my macOS audio player to string replace "xHE-AAC" with "USAC", even though I am using Apple's decoder, which calls itself that in the first place?
My rough, uneducated guess is that, since you're talking about a trademark licensed third-party decoder which calls itself "xHE-AAC" and which, I assume, you didn't modify in any way (you just call it), you may be able to keep calling it the way you do. But when in doubt, please ask the trademark owners (https://www.iis.fraunhofer.de/en/ff/amm/broadcast-streaming/xheaac/trademark-program.html) directly, especially since that question seems to have nothing to do with my encoder.

By the way #1, over the last months I made sure that the audio files generated by exhale can be played back correctly by every xHE-AAC player (if not, please let me know). Again, the only reason why I cannot refer to exhale as an "xHE-AAC encoder" is that it doesn't support USAC's speech coding technology and, therefore, compressed speech sounds pretty bad at the lowest preset.

... exhale in fact does not produce the same high quality results at very low bitrates, that you get from an "official" xHE-AAC encoder.
By the way #2, I agree with this statement on content including speech, like Web radio and audio books, as explained above. But AFAIR, for general music content at 44.1 kHz, no blind comparison between exhale's CVBR mode 'a' (generated e.g. using NetRanger's binaries, without the CBR setting) and the corresponding VBR files of an "official" encoder (generated e.g. using the EZ CD Audio Converter) have been published on this forum. Since HA requires blind test evidence to back up such claims, I need to stress this.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-10-03 23:16:09
I have a feeling that Apple's decoder is non-compliant anyway, since you already had to apply several workarounds in your encoder to guarantee files will decode there.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-10-04 10:52:44
Not several workarounds, only this one (https://gitlab.com/ecodis/exhale/-/commit/4002bff) which Apple know about. The other MPEG-4 file header related things that were fixed during the last year or so were bugs in exhale, not their decoder.

But thanks for reminding me, we should check whether the workaround is still necessary. And, since Windows 11 will be released soon (tomorrow?), I'm curious whether Windows 11 has integrated xHE-AAC decoding capability.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2021-10-04 16:24:27
I'm curious whether Windows 11 has integrated xHE-AAC decoding capability.

Chris

Don't have any high hopes Chris........ it's MS your talking about. ;)
Title: Re: exhale - Open Source USAC encoder
Post by: griploner on 2021-10-04 19:53:47
Yes astonishing it does, I can play a USAC .m4a file in Groove music player... Windows 11 default music player
Title: Re: exhale - Open Source USAC encoder
Post by: soundping on 2021-10-04 20:29:11
I can confirm USAC in windows 11 media player.
Dev channel.
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-10-05 10:48:27
I asked the FhG mailing address about trademark issues. They didn't bother to actually answer me, and only copied and pasted me the FAQ. You'd think a multi-million billion dollar company could afford to actually field emails properly. I guess all that money goes into suing people.
Title: Re: exhale - Open Source USAC encoder
Post by: NateHigs on 2021-10-06 14:03:33
I asked the FhG mailing address about trademark issues. They didn't bother to actually answer me, and only copied and pasted me the FAQ. You'd think a multi-million billion dollar company could afford to actually field emails properly. I guess all that money goes into suing people.

I tend to work on the expectation that the bigger the company, the less likely they are to reply. I'd also say they are unlikely to reply about any trademark issues as they'd have to get the lawyers involved in every response (I don't know an engineer or manager worth their salt who would carry the risk of advising a third party on trademark stuff).

Good effort for trying though. Maybe a few follow up emails would stir up enough interest to generate some kind of useful response. Maybe give them a business email address to reply to?
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-10-06 23:55:08
Haha. Business email address. How about I just do nothing.
Title: Re: exhale - Open Source USAC encoder
Post by: IgorC on 2021-10-12 03:45:21
Intel compiles of exhale-V1.1.7.1-f145f63f with BA_MORE_CBR set now at Rarewares.
Hi John,
Can You please keep two versions on Rarewares, normal and MORE_CBR?

I just downloaded greatest and latest exhale 1.1.7.1 and wondered why quality sucked badly. Then I remembered Chris mentioning 1.1.7.1 with MORE_CBR.  Anyway I got normal 1.1.7 build from http://www.rarewares.org/files/aac/

P.S. Have tried exhale on Android 11. Playback via Android default audio player works. :)
Though foobar2000 resists to play them.
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2021-10-12 08:14:56
@IgorC
U can get the v1.7.1.1 default binaries from HERE (https://hydrogenaud.io/index.php?topic=118888.msg1003509#msg1003509)
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-10-12 08:47:04
Can You please keep two versions on Rarewares, normal and MORE_CBR?

I just downloaded greatest and latest exhale 1.1.7.1 and wondered why quality sucked badly. Then I remembered Chris mentioning 1.1.7.1 with MORE_CBR.
Indeed, and the CBRish mode is experimental and not for general use, as stated behind the macro. I'd actually prefer that, when executables are shared, they are compiled without changes from the GitLab source. To avoid such confusion. (In the past, there may have been some exceptions since people had problems with faulty encodings via foobar2000 conversion e.g., but that should have been sorted out by now).

But keep in mind, very little has changed in exhale's default behavior since version 1.1.7.0, so you can keep using that as well.

Quote
P.S. Have tried exhale on Android 11. Playback via Android default audio player works. :)
Though foobar2000 resists to play them.
For clarification, you're talking about foobar2000 on Android, right?

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2021-10-12 10:25:04
Intel compiles of exhale-V1.1.7.1-f145f63f with BA_MORE_CBR set now at Rarewares.
Hi John,
Can You please keep two versions on Rarewares, normal and MORE_CBR?

I just downloaded greatest and latest exhale 1.1.7.1 and wondered why quality sucked badly. Then I remembered Chris mentioning 1.1.7.1 with MORE_CBR.  Anyway I got normal 1.1.7 build from http://www.rarewares.org/files/aac/

P.S. Have tried exhale on Android 11. Playback via Android default audio player works. :)
Though foobar2000 resists to play them.
Your wish is my command!  ;D  Two sets of compiles are now available. I hope I have indicated the differences sufficiently clearly.
Title: Re: exhale - Open Source USAC encoder
Post by: Shot2 on 2021-10-12 11:50:40
For clarification, you're talking about foobar2000 on Android, right?

Chris

On Android the "foobar2000 Mobile" app (the one by "Resolute", not Peter P.) lacks the ability to play USAC audio. All it can read is their metadata from the mp4 container. One must therefore use other players for USAC on Android - those relying on system libraries work perfectly fine. :)
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-10-12 14:11:32
Thanks, good to know (I'm not using recent Android versions myself).

I can play a USAC .m4a file in Groove music player... Windows 11 default music player
I can confirm USAC in windows 11 media player. Dev channel.
That's awesome! :) Thanks for checking! My own laptop doesn't pass the Windows 11 compatibility check, so I can't install it myself.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: Shot2 on 2021-10-12 22:03:46
That's awesome! :) Thanks for checking! My own laptop doesn't pass the Windows 11 compatibility check, so I can't install it myself.

Chris
FYI: Microsoft (!) provides instructions (https://support.microsoft.com/en-us/windows/ways-to-install-windows-11-e0edbbfb-cfc5-4011-868b-2ce77ac7c70e) on how to install Win11 on unsupported hardware...
/off-topic
Title: Re: exhale - Open Source USAC encoder
Post by: IgorC on 2021-10-12 22:50:51
john33, NetRanger,

Thank You for builds.

Chris,
Yes, I meant foobar2000 Android app.

Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-10-27 09:01:41
I just bumped the version number, having finished some leftover to-dos at the lowest CVBR presets 0, 1, a, and b (there shouldn't be any changes at the other presets). If you successfully build the latest commit (https://gitlab.com/ecodis/exhale/-/commit/7688ab5), please call it release 1.1.8.

Changes since version 1.1.7 from August 2021:

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2021-10-27 10:06:35
All versions now at Rarewares. :)
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2021-10-27 22:23:01
exhale v1.1.8-7688ab50 (Stable)
Built on October 27, 2021, GCC 11.2.0

'BA_MORE_CBR' not enabled
Title: Re: exhale - Open Source USAC encoder
Post by: Corsair on 2021-11-04 23:42:46
I've been doing some testing of my own and I think I found one issue regarding gapless encoding. I've attached 2 WAV files, each about 10 seconds, from the tracks which I use to test how well the gapless encoding/playback works in a lossy codec.
(For anyone interested, they have been taken from this album (https://www.discogs.com/release/2635857-Boccherini-Europa-Galante-Fabio-Biondi-Enrico-Casazza-Ernesto-Braucher-Maurizio-Naddeo-Antonio-Fanti), tracks 11 & 12).

I have tested modes 2-7 (i.e. 80-160kbps) and even using mode 7 I can still hear a click during the track transition.

Apple AAC and Opus have no issues at 96 kbps (VBR) and sound transparent to me.
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-11-05 07:14:16
EZ CD Audio Converter's Fraunhofer xHE-AAC encoder fails on those files as well, at least at 96 kbps VBR.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-11-06 15:10:08
Thanks very much, Corsair, for reporting and kode54 for the further checks. I documented this behavior on GitLab as issue #21 (https://gitlab.com/ecodis/exhale/-/issues/21).

I had actually already implemented code to reduce such clicks a long time ago, but that code only addressed the beginning (i.e., first frame) of the encodings, and some more recent edit-list related changes effectively disabled this code. So it's a good idea to take another look at this. Here are some screenshots of what I managed to integrate into exhale locally so far, I'll try to get this committed to the GitLab repository next week:

Current behavior (top: Corsair's original WAVE files, bottom: exhale 1.1.8.0 behavior)
(https://gitlab.com/ecodis/exhale/uploads/068095aad2ade382b6503da60cc10034/exhale_v118_gapless_issue_1.png)

Desired behavior (will hopefully be committed as a sub-release 1.1.8.1 next week)
(https://gitlab.com/ecodis/exhale/uploads/2420ded5cea0c069d7be751fba786f36/exhale_v118_gapless_issue_2.png)

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: prajaybasu on 2021-11-11 20:31:04
I'm happy to report that I have finally started daily driving USAC (exhale SBR g 108kb/s) after upgrading to devices with Android 11 and Windows 11. My new laptop happens to have a 11th gen processor which is a lot faster than my old 4th gen w/ exhale encodes even with the same number of cores, which just makes it more usable for me. Is 11 the magic number for USAC adoption? 

I encoded parts of my library to test with foobar a few months ago but I really prefer Groove and Samsung Music so now that they both support USAC, I'll be only keeping the FLAC copies on my NAS/desktop.

I've avoided encoding to AAC for long, as my library would still be uncomfortably large for a 128GB phone with 256/320kbps AAC files - sometimes only half the size of the FLAC. Exhale encodes can easily be ~10% of the size of the source FLAC file without having to worry about audible artifacts, which is a lot more viable for offline storage.

The only annoyance with USAC on my device is that there are no controls for DRC, which is causing some sort of loudness equalization effect. So with the volume being lower, the perceived quality is worse than other codecs (without DRC), however the maximum volume is just about enough for my headphones, it's probably better for my ears that way.

Unfortunately, I'll still have to keep some streaming subscriptions due to MPEG-H (3DRA) and Atmos.

Thanks for the encoder.
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2021-11-11 21:30:18
exhale v1.1.8.1-7ebdd630
Built on November 10, 2021, GCC 11.2.0

https://gitlab.com/ecodis/exhale/-/commits/master
Title: Re: exhale - Open Source USAC encoder
Post by: Corsair on 2021-11-11 22:30:42
Thanks @C.R.Helmrich for the fix, I've retested it and I no longer hear any issues. Thanks to @NetRanger as well for the compiles.
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-11-12 00:49:49
Exhale@7ebdd630: ELF 64-bit LSB pie executable, ARM aarch64 for GNU/Linux (https://hydrogenaud.io/index.php?action=dlattach;sa=tmpattach;attach=post_tmp_134208_412e55a2269031e3d5b90f698f515eda;topic=118888)
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2021-11-12 10:34:45
All Windows variants now at Rarewares. :)
Title: Re: exhale - Open Source USAC encoder
Post by: IgorC on 2021-11-13 16:41:43
I'm happy to report that I have finally started daily driving USAC (exhale SBR g 108kb/s) ...
There is evidence that SBR rather provides lower quality than higher at bitrates higher than 60 kbps.

https://hydrogenaud.io/index.php?topic=120936.0
https://hydrogenaud.io/index.php?topic=118888.msg997431#msg997431
Title: Re: exhale - Open Source USAC encoder
Post by: Xerius on 2021-11-21 17:15:33
Got the same album in 16/44 and 24/96. I encoded each track to 192kbps xHE-AAC, OGG Vorbis and OPUS:

exhale yields 60-80% bigger files when the input is 24/96. Here is an example of a 3m36sec long track:
Code: [Select]
  38121260 01-03-Pink_Floyd-On_The_Run-1644.wav
   4955064 01-03-Pink_Floyd-On_The_Run-1644.m4a
   4842683 01-03-Pink_Floyd-On_The_Run-1644.ogg
   5220043 01-03-Pink_Floyd-On_The_Run-1644.opus
 124477508 01-03-Pink_Floyd-On_The_Run-2496.wav
   7831800 01-03-Pink_Floyd-On_The_Run-2496.m4a
   5280611 01-03-Pink_Floyd-On_The_Run-2496.ogg
   5217646 01-03-Pink_Floyd-On_The_Run-2496.opus

Any idea why? Is this a bug in exhale 1.1.8 or is this expected?
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-11-21 21:01:04
This is a feature, not a bug. xHE-AAC, unlike Opus IIRC, changes the number of frames per second when you change the sampling rate, so with 96 kHz sampling rate you need to reduce the CVBR mode if you want a lower bit-rate.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: Jurgga on 2021-11-23 08:39:13
EZ CD Audio Converter 9.5.2 (https://www.poikosoft.com) with Exhale v1.1.8.1 released. Also includes Fraunhofer IIS xHE-AAC update with more sample rates in low bitrate encoding.
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-11-23 22:36:48
Thanks Jurgga, I appreciate the continued improvements in speech compression and xHE-AAC in VBR Q1 (36kbps, which becomes less than 24kbps if there is only speech) 48kHz mono is my preferred choice although I am beginning to fear that I will not use never USAC in my work. If the idea of ​​being able to use only one format for speech on each medium excites me, the absence of a decoder pre-installed even in Windows 10 keeps me from innovating in the same way as the impossibility of reproducing Opus (which has a best support) on iPhones that do not yet reproduce this format when embedded in Webm.

The war of containers after that of formats has tired me. Despite your work today I don't see only better speech than AAC LC, despite the bitrate (since I don't like to hear HE-AAC and in this I am in tune with many in my country).

Hoping not to have to wait for another 1,000 answers (yours was just the number 1,000) to see such a simple problem solved. The users of this forum do not represent the generality of the population and when the choice does not concern personal use, in my opinion, any changes must be postponed.
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-11-24 00:37:04
I think I wrote 2 incomprehensible sentences. My frustration is for operating systems unable to add what is commonly found elsewhere, for example the ability to reproduce standardized formats, like Microsoft years after their own press releases, or when contained in known structures, always Microsoft which for example does not make Opus usable when incorporated in ISO, or Apple, which deserves to be laughed at for the number of years it takes for Ogg and Webm. In summary if one wanted to use the HTML <audio> tag without JS as of today, they still have to provide the same content in multiple formats.

None of those who produce content in this way will change format, making life difficult for those who produce coding software. This is my thought.
Title: Re: exhale - Open Source USAC encoder
Post by: Shot2 on 2021-11-26 14:31:18
FWIW, in spite of announcements that it should work, I can't even make Windows 11 (Pro version, clean install) and its apps (e.g. Groove Music) recognize USAC .m4a files. "This item is in a format we don't support. 0xc00d36b4"
Title: Re: exhale - Open Source USAC encoder
Post by: Jurgga on 2021-11-26 16:59:32
FWIW, in spite of announcements that it should work, I can't even make Windows 11 (Pro version, clean install) and its apps (e.g. Groove Music) recognize USAC .m4a files. "This item is in a format we don't support. 0xc00d36b4"

Has anyone tried the *new* Media Player App for Windows 11 with xHE-AAC ?
Title: Re: exhale - Open Source USAC encoder
Post by: wyup on 2021-12-01 23:20:43
Out of curiosity, which exhale binary build for windows is more optimised/fast, john33's Rarewares or NetRanger's?
Usually rareware's executable size for x64 is half of NetRanger's.
Title: Re: exhale - Open Source USAC encoder
Post by: m14u on 2021-12-02 14:03:42
This is because NetRanger works for the KGB and sets a "Honey Trap" in the binary.
Title: Re: exhale - Open Source USAC encoder
Post by: Porcus on 2021-12-02 16:02:50
At least not for Facebook Ouch my bad: As per TOS8 I shall not claim that Facebook is different from a malicious dictatorship, as long as I have no evidence but the sighted evaluation of the glossy appearance.
Title: Re: exhale - Open Source USAC encoder
Post by: enry2k on 2021-12-11 12:13:51
I habe being testing exhale encoder, it's a great piece of software, thank you, It also sounds excellent, even at the lowest bitrates, it outperforms the reference fdk standard he-aac encoder at 48 kbps in some speech that I have encoded, the file ended with fdk aac encoder presents the typical SBR high pitched annoying artifacts, while the file encoded with exhale and eSBR is free from annoying artifacts.
I would like to know: What ids the ifference between the standard SBR and the enhanced spectral band replication improvement? What are the other new tools supported in exhale, which are not present in a standard aac encoder?
Title: Re: exhale - Open Source USAC encoder
Post by: enry2k on 2021-12-11 16:38:46
Sorry, I have realized that I have mistyped a couple of words, please accept my apologize for the inconvenience, this is the correct text I intended to post:
Hi, I have being testing exhale encoder, it's a great piece of software, thank you, It also sounds excellent, even at the lowest bitrates, it outperforms the reference fdk standard he-aac encoder at 48 kbps in some speech that I have encoded, the file encoded with fdk aac encoder presents the typical SBR high pitched annoying artifacts, while the file encoded with exhale and eSBR is free from annoying artifacts.
I would like to know: What is the difference between the standard SBR and the enhanced spectral band replication upgrade technically? What are the other new tools supported in exhale, which are not present in a standard aac encoder?

I hope I fixed all errors in my text message.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-12-11 22:06:14
You can find a comprehensive description of the new coding tools in the xHE-AAC (or USAC) standard in this journal article:
https://www.gel.usherbrooke.ca/gournay/documents/publications/JAES_V61_12_PG956.pdf
eSBR, for example, is described in Section 3.3, but note that exhale doesn't implement the improvements described in subsections 3.3.2-3.3.5. The main cause of the improvements you hear is probably that exhale lets the SBR coding start at a higher frequency than some other HE-AAC encoders.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: soundping on 2021-12-12 03:46:02
Has anyone tried the *new* Media Player App for Windows 11 with xHE-AAC ?
Media Player preview will not play anything because of errors.
Title: Re: exhale - Open Source USAC encoder
Post by: enry2k on 2021-12-12 10:25:32
Thank you for your reply, I am eager to read the article.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-12-12 11:00:20
Regarding
Has anyone tried the *new* Media Player App for Windows 11 with xHE-AAC ?
Media Player preview will not play anything because of errors.

I also see these posts from October:
Yes astonishing it does, I can play a USAC .m4a file in Groove music player... Windows 11 default music player
I can confirm USAC in windows 11 media player.
Dev channel.

I'm confused. Didn't you and griploner write in the above messages that it works? Are we talking about different versions of the Windows 11 Media Player? Which one is the default version on a fresh Windows 11 (not Developer preview) installation?

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: soundping on 2021-12-12 11:15:02
Classic Windows Media Player works just fine, but Media Player preview is full of errors.

Title: Re: exhale - Open Source USAC encoder
Post by: Shot2 on 2021-12-12 11:57:31
USAC probably does not work -yet- in Windows 11 Pro (the current vanilla release 21H2 22000.348; not dev builds or other esoteric stuff).
No matter the player used: neither Windows Media Player (WMP, the old-style player inherited from the last century) nor Groove Music (the default music app and player for .m4a) can decode the audio, with only one error message (hence not "full of errors").
Title: Re: exhale - Open Source USAC encoder
Post by: soundping on 2021-12-12 12:36:04
Both players install on Dev build (Win11) and run separately.

I've played around with the preview version and got the permissions set correctly now, so it will play m4a at 40 kbps.
Title: Re: exhale - Open Source USAC encoder
Post by: Shot2 on 2021-12-12 12:39:53
Both players install on Dev build

Which build?
Title: Re: exhale - Open Source USAC encoder
Post by: soundping on 2021-12-12 12:57:32
The Dev channel
Build 22518.1012

https://blogs.windows.com/windows-insider/2021/11/16/new-media-player-for-windows-11-begins-rolling-out-to-windows-insiders/
Title: Re: exhale - Open Source USAC encoder
Post by: Shot2 on 2021-12-12 13:27:12
The Dev channel
Build 22518.1012

https://blogs.windows.com/windows-insider/2021/11/16/new-media-player-for-windows-11-begins-rolling-out-to-windows-insiders/

Thanks. It might take months till such new beta/dev features land in the mainstream releases (if they ever do properly! see e.g. Opus metadata in Groove Music)...
USAC/xHE-AAC remain unsupported on Windows 11 for the time being. :(
Title: Re: exhale - Open Source USAC encoder
Post by: Corsair on 2021-12-16 20:16:06
I've just upgraded from Mac OS Big Sur directly to Monterey v12.1 on Apple M1 Air and foobar2000 (M1 native version) can no longer play USAC M4A files. The error message says "Playback error: unsupported format or corrupted file".

Has anyone else experienced this?
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-12-17 07:07:28
This appears to be a bug in how the system codecs are invoked to support that format. This bug does not appear to affect Cog, which also doesn't implement support in the same way.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-12-17 10:05:45
I bumped exhale's version number one last time and finished a 1.1.9 release candidate. The only difference to the intermediate 1.1.8.1 from early November is that the exhale command-line application now writes a encoder name and version string as a "tool" tag into the MPEG-4 header, so programs like foobar2000 can display "exhale 1.1.9" in their File properties dialogs.

Please report any problems you might have with this additional metadata tag. I'll make a final 1.1.9 release tag at the end of the year.

Changes since version 1.1.8 from October 2021:

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2021-12-17 13:31:22
I'm currrently away from home until after 7 January. I have created compiles which I will attempt to upload to Rarewares later today. :)
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-12-18 06:49:19
I attempted to port libvorbis's linear predictor into the gapless extrapolator, and it appears to have zero difference from what's currently in place. I'll stash the changes anyway, in case anyone finds them useful.

https://gist.github.com/kode54/20f035dee343f5668796cad46be78d8b

(Original code modified to use in-place variable length arrays instead of alloca())

Binaries for macOS Universal Intel+ARM:
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2021-12-18 12:27:29
exhale-V1.1.9-00423757 standard compiles now at Rarewares. I believe they are all OK, but let me know if there is a problem. :)
Title: Re: exhale - Open Source USAC encoder
Post by: jlw_4049 on 2021-12-22 15:30:14
I've read through this pretty well, if someone doesn't mind me asking.

How is the compatibility as far as hardware/streaming devices go for this codec? Does it decode the same way as AAC or is it something that will have to be added to hardware etc?

Thank you and I apologize if it was already answered in this thread.
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-12-28 07:18:21
Thought I'd mention here. FFmpeg 4.4.1 doesn't handle seeking properly to the start of eSBR encoded files. It always seeks to the second frame in the file, not the first.
Title: Re: exhale - Open Source USAC encoder
Post by: IgorC on 2021-12-29 15:40:07
How is the compatibility as far as hardware/streaming devices go for this codec?
There is no sense to talk about hardware compatibility as today all gadgets, smartphones and smartTVs run some sort of OS.
Nowdays it's all about software support and updates/upgrades. 

Right now xHE-AAC support is somewhat limited. The good news is that big companies have already started to adopt xHE-AAC.  So it's a matter of time.

Does it decode the same way as AAC or is it something that will have to be added to hardware etc?
xHE-AAC is a new format, different from AAC, HE-AACv1/v2. It requires its own decoder.
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2021-12-29 17:47:56
There is no sense to talk about hardware compatibility as today all gadgets, smartphones and smartTVs run some sort of OS. Nowdays it's all about software support and updates/upgrades. 

Right now xHE-AAC support is somewhat limited. The good news is that big companies have already started to adopt xHE-AAC.  So it's a matter of time.

It wouldn't make sense, because any mobile or tablet on the market decodes compressed audio with xHE-AAC or MPEG USAC.
Instead, the problem is precisely the large companies such as Microsoft, which despite the press release of 1 July 2020 (https://www.audioblog.iis.fraunhofer.com/fraunhoferiis-xheaac-microsoft), have not yet maintained what was announced.

For those who produce content it is a gamble, you run the risk of finding support in apps or in the browser instead of the operating system and only for Windows 11 whose adoption rate is slow. An integrated decoder would also be needed in Windows 10 but the user who uses Linux or FreeBSD would still remain uncovered.

At that point I distribute the content in Opus contained in WebM and I am sure it will work everywhere except iPhone and iPod touch. And since Apple already supports it for macOS and iPadOS, you'll need to change containers on the fly just for their browsers, and probably for less time than what Microsoft has lost since its announcement.

Opus is currently the most compatible of the new hybrid formats. I am thinking about it seriously, obviously not for music because I just work with speech. I have demonstrated what is written in another discussion (https://hydrogenaud.io/index.php?topic=121779.msg1006023#msg1006023).
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2021-12-30 06:53:14
Thought I'd mention here. FFmpeg 4.4.1 doesn't handle seeking properly to the start of eSBR encoded files. It always seeks to the second frame in the file, not the first.

Disregard this. It was a combination of my seek code being bad, and these files having code I didn't expect.

Basically:

On seek, I needed to remove the AVSEEK_FLAG_ANY flag so that it would be guaranteed to seek to keyframes.
Then, I needed to move my seek correction sample skipping code to a spot after a packet is successfully decoded. The reason for this, is the first preroll packet has a timestamp of -2048, so it was originally trying to skip 2048 samples. But, this packet causes the decoder to return an EAGAIN error, asking for another packet before it can decode anything. So instead, it should only compare the packet timestamp to the wanted offset after successfully decoding. This also works on track start, since it will also preroll and decode two packets, producing one packet of audio, and skipping 0 samples.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2021-12-30 11:54:34
Thanks for the info. So am I correct in concluding that this has nothing to do with exhale itself, i.e., exhale is operating as expected?

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2022-01-01 00:38:57
Yes, exhale was operating as expected. The only thing was that some eSBR and PS? or whatever feature using files produced by EZ CD did not have a preroll frame of any sort, so they didn't trip the issue in my seeking code, so I didn't notice it until now.
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2022-01-05 15:24:06
exhale v1.1.9-00423757
Built on January 05, 2022, GCC 11.2.0

https://gitlab.com/ecodis/exhale/-/commits/master

https://gitlab.com/ecodis/exhale/-/releases
Title: Re: exhale - Open Source USAC encoder
Post by: audiodigger on 2022-01-06 17:36:49
Hello all,

Thanks to everyone working on and with Exhale.  I stumbled across it and have starting using it to encode music and speech.  I am on Win 7.  The only decoder I have found is kode54 packet decoder for Foobar. (thank you).  I would like to be able to decode through command line app.

Would someone point me to the reference software that will decode exhale back to wave?

Thank you.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2022-01-07 11:35:41
Do decode from the command-line, you can use an FFmpeg build with the latest FDK-AAC included. If you know how to compile FFmpeg yourself with the "non-free" extensions enabled, I recommend you do that. If not, I found the following page which links to precompiled binaries for Windows:

https://www.reddit.com/user/VeritablePornocopium/comments/ccilei/ffmpeg_with_libfdk_aac_for_windows_x64/

Under "Static builds - ffmpeg.exe" you can find a still working Mega.nz link. I haven't tried the downloaded executable yet and I'm not responsible for it (so use it at your own risk!), but it shows it was built with --enable-libfdk-aac when run without arguments from the command prompt.

The official ISO/MPEG reference decoder for USAC is closed-source and not publicly available.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: audiodigger on 2022-01-07 13:19:36
Thank you Chris for the link and the information.

I downloaded the ffmpeg from the link and tried to decode.  It gave me the same output that I was receiving from my self compiled ffmpeg with libfdkaac.

from ffmpeg output:

[aac @ 0000000002f91340] Audio object type 42 is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented.
[mov,mp4,m4a,3gp,3g2,mj2 @ 0000000002f7e980] Failed to open codec in avformat_find_stream_info

[aac @ 0000000002f91340] Audio object type 42 is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented.
Guessed Channel Layout for Input Stream #0.0 : stereo
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cgga.m4a':
  Metadata:
    major_brand     : mp42
    minor_version   : 0
    compatible_brands: mp42isom
    creation_time   : 2021-12-29T23:32:58.000000Z
    encoder         : exhale 1.1.9
  Duration: 00:03:14.46, start: 0.000000, bitrate: 140 kb/s
    Stream #0:0(und): Audio: aac (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 139 kb/s (default)
    Metadata:
      creation_time   : 2021-12-29T23:32:58.000000Z
      handler_name    : crh
[aac @ 000000000374cb00] Audio object type 42 is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented.
Stream mapping:
  Stream #0:0 -> #0:0 (aac (native) -> pcm_s16le (native))
Error while opening decoder for input stream #0:0 : Function not implemented

The song was encoded with exhale at 5.

It looks like AOT 42 has not been implemented in ffmpeg.  I remember seeing a request for ffmpeg to support type 42.

Any other recommendations or suggestions?
Title: Re: exhale - Open Source USAC encoder
Post by: Case on 2022-01-07 13:52:23
To decode with ffmpeg you need to tell it to use fdkaac. ffmpeg -c:a libfdk_aac -i <input> <output>.
Title: Re: exhale - Open Source USAC encoder
Post by: audiodigger on 2022-01-07 14:20:05
Thank you Case.

That fixed the issue I was having.  I really appreciate the help. 
Title: Re: exhale - Open Source USAC encoder
Post by: audiodigger on 2022-01-07 15:08:59
Update

to decode
ffmpeg -c:a libfdk_aac -i input.m4a output.wav

to play
ffplay -codec:a libfdk_aac -i input.m4a

I assumed that -c:a would work with ffplay.  It did not work for me.
Title: Re: exhale - Open Source USAC encoder
Post by: kode54 on 2022-01-08 23:51:50
And if you're on macOS, and have enabled AudioToolbox support in your copy of FFmpeg, you can decode them with:

ffmpeg -c:a aac_at -i input.m4a output.wav

and to play
ffplay -codec:a aac_at -i input.m4a

Note that if you're on Monterey, you need one (or preferably two) patches I've produced and submitted to the FFmpeg upstream:

https://gist.github.com/kode54/5c5005be2365ef7c4592f9cbccb898bc

The first patch makes AudioToolbox actually work. The second makes it so that all the known likely float formats actually output floating point instead of integer format.
Title: Re: exhale - Open Source USAC encoder
Post by: Gravitator on 2022-01-13 12:18:57
Has the encoding limit for AAC been reached?
Title: Re: exhale - Open Source USAC encoder
Post by: IgorC on 2022-01-13 13:20:34
Has the encoding limit for AAC been reached?
Your question isn't clear.
Title: Re: exhale - Open Source USAC encoder
Post by: Gravitator on 2022-01-14 05:58:10
Should we expect new compression methods? It looks like the OPUS has already hit the wall. Video coders continue to improve.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2022-01-14 10:11:42
Should we expect new compression methods?
Not for the bit-rates supported by exhale (40 kbps or more for stereo, or equivalent rate for multichannel). There, MPEG-H Audio probably provides the best audio quality, assuming a good encoder with good VBR, of course. At less than 40 kbps stereo (or equivalent multichannel rate), we might see some slight improvements in the future, though. There's the 3GPP IVAS standard expected to be finalized in 2024, see my overview at http://www.ecodis.de/audio.htm#evs, and at very low bit-rates, lots of promising machine learning based research is currently being conducted, see also my outlook from almost 4 years ago at http://www.ecodis.de/audio.htm#summary

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: wyup on 2022-04-10 10:42:34
No messages or updates for almost 3 months.. everything allright? :-\
Title: Re: exhale - Open Source USAC encoder
Post by: jarsonic on 2022-04-11 20:03:23
I think it's more likely that it's pretty stable as-is, and has hit the major goals of his project.
Title: Re: exhale - Open Source USAC encoder
Post by: Ziengaze on 2022-04-29 08:52:42
Does anyone else experience issues with their Windows compiles since commit f145f63f?

Code: [Select]
acd53a21.exe 5 Audio.wav Audio.m4a

  ---------------------------------------------------------------------
 | exhale - ecodis extended high-efficiency and low-complexity encoder |
 |                                                                     |
 | version 1.1.7 (x64, built on Apr 29 2022) - 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 135.0 kbit/s

 Input statistics:  File loudness -6.65 LUFS,   sample peak level -0.02 dBFS
Code: [Select]
f145f63f.exe 5 Audio.wav Audio.m4a

  ---------------------------------------------------------------------
 | exhale - ecodis extended high-efficiency and low-complexity encoder |
 |                                                                     |
 | version 1.1.7 (x64, built on Apr 29 2022) - 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 71.3 kbit/s

 Input statistics:  File loudness -6.65 LUFS,   sample peak level -0.02 dBFS

Seems like the bitrates for stereo input are suddenly way too low.
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2022-04-29 15:38:28
This is an estimate, even Fraunhofer's encoder at 36kbps VBR produces monophonic files below 24kbps when they contain only voice. Finally you are using an older release, the latest commit is:
https://gitlab.com/ecodis/exhale/-/archive/master/exhale-master.zip

I'm not a Windows user, especially from the command line; I have compiled the latest commit, downloaded a track that we can all use ( http://www.lindberg.no/hires/test/2L-125_stereo-44k-16b_04.flac ) and this is the result:

./exhale 5 2L-125_stereo-44k-16b_04.wav 2L-125_stereo-44k-16b_04.m4a

  ---------------------------------------------------------------------
 | exhale - ecodis extended high-efficiency and low-complexity encoder |
 |                                                                     |
 | version 1.1.9 (ARM, built on Apr 29 2022) - 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 145.7 kbit/s

 Input statistics:  File loudness -22.96 LUFS,   sample peak level -6.25 dBFS
Title: Re: exhale - Open Source USAC encoder
Post by: Ziengaze on 2022-04-29 16:42:48
Finally you are using an older release
Because it's the last working commit for me.
Code: [Select]
exhale.exe 5 2L-125_stereo-44k-16b_04.wav 2L-125_stereo-44k-16b_04.m4a

  ---------------------------------------------------------------------
 | exhale - ecodis extended high-efficiency and low-complexity encoder |
 |                                                                     |
 | version 1.1.9 (x64, built on Apr 29 2022) - 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 87.3 kbit/s

 Input statistics:  File loudness -22.96 LUFS,  sample peak level -6.25 dBFS
Code: [Select]
./exhale 5 2L-125_stereo-44k-16b_04.wav 2L-125_stereo-44k-16b_04.m4a

  ---------------------------------------------------------------------
 | exhale - ecodis extended high-efficiency and low-complexity encoder |
 |                                                                     |
 | version 1.1.9 (x64, built on Apr 29 2022) - 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 145.7 kbit/s

 Input statistics:  File loudness -22.96 LUFS,  sample peak level -6.25 dBFS
Linux seems fine but Windows still shows the same strange behaviour with git master.
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2022-04-29 18:05:05
Meanwhile I tried Windows 10 with Snapdragon 850 and the error doesn't show up, it seems confined to Windows for Intel processors. I'll try with 32-bit processors later.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2022-04-29 21:20:13
Sorry, Ziengaze, I cannot reproduce the phenomenon you're observing. All Windows compiles I tried (John's from post 1025 (https://hydrogenaud.io/index.php?topic=118888.msg1005864#msg1005864) and my own), from the most recent commit on GitLab, produced 145.7 kbps on that 2L-125_stereo... audio file. Which Windows compiler are you using exactly, and on which Windows version exactly?

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: Ziengaze on 2022-04-29 22:21:34
Built on windows 10 21h1 using msys2 with gcc 11.3.0.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2022-05-01 22:30:10
So Ziengaze and I have done several other tests. All other compilers mentioned above, plus clang 14, have no problem compiling exhale. Also, the faulty compile only has problems with CVBR modes 5 and higher (non-SBR) as well as f and higher (SBR), which allowed us to trace the issue to very few changes made in exhale's source file lib/exhaleEnc.cpp. The strange thing is that NetRanger's last compile in this post (https://hydrogenaud.io/index.php?topic=118888.msg1006531#msg1006531) seems to be fine, while Ziengaze's compile with the same gcc version seems faulty.

We just can't figure out what the problem is. Any help is greatly appreciated.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: doccolinni on 2022-05-02 07:18:46
Also, the faulty compile only has problems with CVBR modes 5 and higher (non-SBR) as well as f and higher (SBR), which allowed us to trace the issue to very few changes made in exhale's source file lib/exhaleEnc.cpp.

That sounds like a job for unit testing.
Title: Re: exhale - Open Source USAC encoder
Post by: wyup on 2022-05-06 15:17:47
Do decode from the command-line, you can use an FFmpeg build with the latest FDK-AAC included. If you know how to compile FFmpeg yourself with the "non-free" extensions enabled, I recommend you do that. If not, I found the following page which links to precompiled binaries for Windows:

https://www.reddit.com/user/VeritablePornocopium/comments/ccilei/ffmpeg_with_libfdk_aac_for_windows_x64/

Under "Static builds - ffmpeg.exe" you can find a still working Mega.nz link. I haven't tried the downloaded executable yet and I'm not responsible for it (so use it at your own risk!), but it shows it was built with --enable-libfdk-aac when run without arguments from the command prompt.

The official ISO/MPEG reference decoder for USAC is closed-source and not publicly available.

Chris

Is there any option to include the exhale source encoder in ffmpeg as a non-free FDK-AAC build?
This would prove very useful since ffmpeg is the most convenient transcoder tool out there.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2022-05-06 17:54:41
In the early days of exhale development, someone already mentioned this in FFmpeg ticket #8411 (https://trac.ffmpeg.org/ticket/8411), but I decided this is too much work for me, and the FFmpeg developers don't seem to be interested very much (judging from the response to that ticket). Others would have to write exhale wrapper code for FFmpeg.

It's also not trivial since I believe exhale would have to be run in a two-pass fashion, with the first pass required to collect frame loudness information and the second pass for the actual audio encoding using the loudness data from the first pass. The only other xHE-AAC encoding plug-in available for FFmpeg that I'm aware of, the one by MainConcept and Fraunhofer IIS (https://www.mainconcept.com/ffmpeg), requires such a two-step approach, as shown in Sec. 4. Plugin Usage of their User Guide (https://www.mainconcept.com/hubfs/PDFs/User%20Guides/MainConcept%20xHE-AAC%20Encoder%20Plug-In%20for%20FFmpeg%20User%20Guide.pdf).

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: Verónica Thorn on 2022-05-13 18:35:18
Are there any more updates planned regarding quality?
Would you consider it almost transparent at 192kbps? I think in the forum test. the Apple LC-AAC had a score around 4.94
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2022-05-14 15:20:15
There are no updates planned, the latest exhale version achieves a mean opinion score of about 4.9 with CVBR preset 9, see this post and the following one (https://hydrogenaud.io/index.php?topic=120007.msg989184#msg989184) for a blind test of a fix which was published in exhale later. And 4.9 was my goal from the start.

There is, however, an undocumented command-line which you can use to turn off the USAC noise filling functionality at CVBR preset 9 (it doesn't make any sense at lower-bitrate presets):

For 22 and 44.1 kHz input: exhale.exe 9 n 43 input.wav output.m4a
For 24 and 48.0 kHz input: exhale.exe 9 n 50 input.wav output.m4a

My ears aren't good enough anymore to tell a difference at ~192 kbps, but if someone is really interested in getting the maximum audio quality out of exhale at this bit-rate, feel free blind-test the default command-line against the above one and report whether there is any improvement by the latter on any audio content. If so, I might change CVBR preset 9 accordingly.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2022-05-22 18:32:32
Just a new compile with the latest GCC.

exhale v1.1.9-00423757 (Release)
Built on May 22, 2022, GCC 12.1.0

https://gitlab.com/ecodis/exhale/-/commits/master
Title: Re: exhale - Open Source USAC encoder
Post by: sheik124 on 2022-05-26 18:29:07
Do decode from the command-line, you can use an FFmpeg build with the latest FDK-AAC included. If you know how to compile FFmpeg yourself with the "non-free" extensions enabled, I recommend you do that.
You can take it a bit further if you want. Compile ffmpeg (and ffplay) with
Code: [Select]
--disable-decoder=aac
--disable-encoder=aac
--disable-decoder=aac_fixed
--enable-libfdk-aac
This disables all of ffmpeg's internal AAC decoding - so you'll never get any error codes about AOT 42 even if you don't remember to pass -acodec libfdk_aac to ffplay or prefix your ffmpeg -i with -c:a libfdk_aac. "It just works." ffmpeg will now also default to libfdk_aac, libopus, and libvorbis in any context where it needs to encode for output. USAC playback is drag/drop to ffplay without needing to write an admittedly simple .bat script to handle it, and if you build mpv from here, it'll work there too.

You can apply that to a lot of other codecs that have "iffy" ffmpeg implementations (opus/vorbis) or have faster alternatives (dav1d) as long as you're including the appropriate external library. Disable some MP2 encoders too while you're at it...
Code: [Select]
--disable-encoder=opus
--disable-decoder=opus
--enable-libopus
--disable-decoder=vorbis
--disable-encoder=vorbis
--enable-libvorbis
--disable-encoder=mp2
--disable-encoder=mp2fixed
--enable-libtwolame
--disable-decoder=av1
--disable-decoder=libaom
--enable-libdav1d
Title: Re: exhale - Open Source USAC encoder
Post by: jprjr on 2022-06-09 01:58:18
Hi all, I had a question about USAC encoding that I asked on the project gitlab, but figured I'd ask here, too, in case anybody knows. https://gitlab.com/ecodis/exhale/-/issues/23

So, I'm working on a program that will read in a FLAC Icecast stream, then re-encode it to HLS in different codecs, I've been successful with the standard AAC, as well as ALAC and FLAC in fragmented mp4.

I wanted to integrate the Exhale library to add USAC as an option. But there's a part of the HLS specs that has me thrown:

Quote
2.22. For xHE-AAC, loudness metadata MUST be present according to the Basic Loudness Metadata specified in ISO 23003-4 Table I.5; samplePeakLevel or truePeakLevel MUST be present. The methodDefinition SHOULD be 2 for video content.

I'm reading in audio and immediately encode it, and everything I've seen about loudness metadata requires 2 passes. But for a live audio source, I assume there must be some method of essentially saying no, there is no loudness metadata, or a kind of "null" loudness metadata, that states the audio should just be decoded as-is, without any dynamic range correction applied.

In the Exhale API you can set a few different loudness-related fields, but they all reference tables from the standards, which I don't have. I didn't know if anybody can help craft what these fields should be set to to signal that there's no/empty DRC? I just want the audio to be decoded using the same methods as the other codecs.

The fields, for reference:

Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2022-06-09 21:45:42
I'll write a detailed answer on Gitlab on the weekend. A short answer for now:

Indeed, unlike in AAC, loudness metadata must be present in xHE-AAC. Therefore, you, as a user of this Extended HE-AAC encoding library, must take care of on-the-fly loudness normalization (similar top what's being done on the radio) to -23 LUFS. In general, I highly recommend you use a properly tested and certified commercial solution incorporating such loudness normalization and HLS interfacing - exhale wasn't developed for your "live streaming" use case, and unfortunately, I won't be able to help you very much.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: jprjr on 2022-06-09 22:20:42
Thank you for the response.

Unfortunately, all the commercial solutions I've found start at ~$1,000 (or you need to contact for a quote, which I assume is going to be in the thousands), and this is for a hobby project. My budget is effectively $0 + my free time.

I do look forward to reading the detailed response, the reason I do all this is for learning, so thank you in advance for helping me learn more about all this tech.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2022-06-12 20:00:18
I confess that, in an attempt to maintain backward compatibility with exhale's initial API, the loudness info pass-over got pretty complicated. Don't know yet about the bsSamplePeakLevel for -1 dBFS (let's figure this out privately and update this post later  - done), but revisiting app/exhaleApp.cpp, I was able to collect the following numbers for you:


Chris
Title: Re: exhale - Open Source USAC encoder
Post by: Bossesand on 2022-06-12 20:22:38
A Quick question about encoding, I  have 6 and 8 channel WAV files that I want to encode as hexagonal and octagonal that is 6.0 and 8.0 ( and eventually  16.0 ) without lfe lowpass filtering, this is for Ambisonics.
Can this be done with exhale?
If so how? What parameters to use?
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2022-06-13 09:00:17
Sorry, no, exhale, as an Extended HE-AAC encoder, doesn't support 6.0 and 8.0 audio. The xHE-AAC standard suite itself doesn't even support 5.1 (it specifies mono and stereo audio only).

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2022-06-30 08:20:15
Small update pushed to Gitlab (https://gitlab.com/ecodis/exhale/-/commit/4ef4bc3c) for a 1.1.9.1 sub-release, fixing compilation issues for users of the C-style library API (probably not you, John and NetRanger) and a warning which I discovered in this log file (https://gitlab.com/ecodis/exhale/uploads/19aca658fd53c3e598e4c7b0c4c2709c/ab-suite.build.log). No audio quality changes, the compressed audio produced by version 1.1.9.1 should be identical to that of the last tagged release 1.1.9 of December. If not, please let me know.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2022-06-30 09:20:40
exhale v1.1.9.1-4ef4bc3c
Built on June 30, 2022, GCC 12.1.0
Title: Re: exhale - Open Source USAC encoder
Post by: jprjr on 2022-07-05 22:29:55
Small update pushed to Gitlab (https://gitlab.com/ecodis/exhale/-/commit/4ef4bc3c) for a 1.1.9.1 sub-release, fixing compilation issues for users of the C-style library API (probably not you, John and NetRanger) and a warning which I discovered in this log file (https://gitlab.com/ecodis/exhale/uploads/19aca658fd53c3e598e4c7b0c4c2709c/ab-suite.build.log). No audio quality changes, the compressed audio produced by version 1.1.9.1 should be identical to that of the last tagged release 1.1.9 of December. If not, please let me know.

Chris

Hi there - could you push up a 1.1.9.1 tag? I'm thinking of Linux distros that prefer to track tags rather than commits. Thank you!
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2022-07-12 12:02:57
jprjr, your last commit(s) after the 1.1.9.1 sub-release change the encoded bitstreams, apparently the operation of the TNS filter detector has changed. I tested with NetRanger's compiles Let's discuss offline whether/how we can change your fix to make the resulting bitstreams identical to those of exhale release 1.1.9.1 (which seems to behave identically to last year's 1.1.9 in my tests).

Update (July 18): fixed, see https://gitlab.com/ecodis/exhale/-/merge_requests/11

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: zmashine on 2022-07-21 12:00:42
exhale v1.1.9.1-4ef4bc3c
Built on June 30, 2022, GCC 12.1.0
with this build and preset 9 output files have avg bitrate ~128 kbps.
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2022-07-21 19:03:35
jprjr, your last commit(s) after the 1.1.9.1 sub-release change the encoded bitstreams, apparently the operation of the TNS filter detector has changed. I tested with NetRanger's compiles Let's discuss offline whether/how we can change your fix to make the resulting bitstreams identical to those of exhale release 1.1.9.1 (which seems to behave identically to last year's 1.1.9 in my tests).

Update (July 18): fixed, see https://gitlab.com/ecodis/exhale/-/merge_requests/11

Chris


Would be gr8 to see this fixed being pushed into the master so...............
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2022-07-22 14:13:03
Now seems to be fixed:
https://gitlab.com/ecodis/exhale/-/tree/master
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2022-07-22 19:09:13
exhale v1.1.9.1-71f2a4ab
Built on July 22, 2022, GCC 12.1.0

https://gitlab.com/ecodis/exhale/-/commits/master
Title: Re: exhale - Open Source USAC encoder
Post by: 1337Rainboom on 2022-07-23 20:44:54
Hello,
There's a song that has instruments at 11.25khz and exhale seems to only fill individual frequencies up to 11khz so it is removing the instrument.. is there a way to set the cutoff for filling in individual frequencies higher?
Thanks
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2022-07-24 13:00:17
Hi,

which of exhale's bit-rate presets are you using? And which sampling rate is your input audio at? If you could post a few seconds of your audio file, that may also help.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: 1337Rainboom on 2022-07-25 00:46:59
Preset B and Preset C
Both seem to have pretty similar tuning (at least, looking at a spectrogram)... relatively accurate frequencies up to 11khz and then it  goes really, really inaccurate to the point where an instrument isn't audible in the audio anymore or it just outright removes it
I would rather it go up to 11.25 or 11.5khz and spend an extra kbps or two.. if there's an instrument it is cutting off
Audio is 44.1khz
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2022-07-25 21:07:07
That's a limitation of exhale's SBR encoder. Try using preset 2 or 3 instead of the letters, or resample your input to 48 kHz before encoding.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: 1337Rainboom on 2022-07-26 00:33:49
Thanks!
Resampling to 48khz brought back some of the instrument
It's not nearly as audible as the original audio source but at least it's partially there
Looks like it raised the frequency cutoff about 500-750hz, nice
Interestingly, 48khz is 55kbps and 44.1khz is 57kbps...
Title: Re: exhale - Open Source USAC encoder
Post by: 1337Rainboom on 2022-07-26 01:14:33
Definitely closer to the original
Title: Re: exhale - Open Source USAC encoder
Post by: Gravitator on 2022-07-28 21:13:36
Привет!
From 12-25 seconds, cymbal suppression is noticeable.
> Download (https://files.videohelp.com/u/227452/Ozzy%20Osborne%20-%20No%20More%20Tears.7z)
Title: Re: exhale - Open Source USAC encoder
Post by: Fierce vinegar on 2022-08-06 16:32:21
can someone help me im trying to play xhe audio on my galaxy s7 but it wont recognize the files, how do i make it work
Title: Re: exhale - Open Source USAC encoder
Post by: Brazil2 on 2022-08-07 01:03:57
can someone help me im trying to play xhe audio on my galaxy s7
You can't. Because the lastest update for the S7 is running Android 8 and you need at least Android 9 for xHE-AAC playback.
Title: Re: exhale - Open Source USAC encoder
Post by: 1337Rainboom on 2022-08-12 05:32:12
Exhale seems to be having an especially hard time encoding this... It generally encodes pianos pretty well but somehow not this... the bitrate is also a little high (averaged 73kbps for preset b)
preset b does sound better than preset a but it's still more artifacting than I'd expect.. I'm pretty sure even preset d
It kinda sounds wavy/ping-pong like
It seems to be the high pitched instrument causing the really high bitrate
Original is 44.1khz, I upsampled to 48khz

I guess.. the level of artifacting isn't that unusual for the presets used... I am still curious why the high pitched instrument is causing the bitrate spike
ohhhh.. I just looked at a spectrogram.. I think I see why.. there's a lot of frequencies to fill in?

Anyway, it does seem like I was being over sensitive to the artifacting on the piano... I can hear the strings broken up a bit as well.. but I don't think the level of artifacting is unusual for the presets used, I guess the piano artifacting just seemed especially annoying to me
And the bitrate spike seems to be because there's a LOT of 7khz+ frequencies to fill in.. so, mystery solved
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2022-08-13 00:00:08
Indeed, that audio snippet is a tough one to encode. But I find that, compared to e.g. Winamp's HE-AAC encoder at the same bit-rate (72 kbps for comparison with preset b), exhale still sounds quite acceptable.

Thanks for sharing that sample!

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: 1337Rainboom on 2022-08-13 06:41:23
Can't tell if Fraunhofer xHE-AAC or exhale encodes it better but both are really good! I think they are tuned quite differently (Fraunhofer seems to retain the higher frequencies on this sample better to my ears)
I also find LC-AAC exhale might win against Apple in a good amount of cases?
Then again, I think Musepack at 90kbps setting might of won against 96kbps Apple AAC on this sample.. at least, with a few quick listens (Musepack averaged 130kbps, Apple AAC 135kbps)
But yeah, all the encoders averaged high.. I think Opus may have actually averaged a bit more sane (would have to check again)
I think Opus does really well when there's a lot of noisy frequencies to encode so I could see how it'd do well on this
Well, I guess the loud 7khz+ frequencies aren't tripping up Opus as much so it gains a lot of efficiency there
Title: Re: exhale - Open Source USAC encoder
Post by: 1337Rainboom on 2022-08-14 08:44:08
Exhale seems to be adding "scratchy" sounds to this section
Even by preset c it's still quite audible...
Especially at about 0:09... for a split second it has massive artifacting
wait, I hear the same sound in the uncompressed audio... but it seems to be amplifying it?
It seems to be duplicating it... even by preset d it's quite audible, albeit a bit less
Although most of the really audible scratchy sounds disappear by preset d... it's pretty faint by that point to where you really have to listen
Title: Re: exhale - Open Source USAC encoder
Post by: 1337Rainboom on 2022-08-18 23:32:24
Is it just my imagination or does Exhale have some slight underwater/muffled distortion and weirdness with the stereo compared to other HE-AAC encoders?  It's pretty minor but now that I notice it, it bugs me a little... I don't think it's just my imagination
It almost sounds like the stereo is slightly widened from the original audio?
I wonder if the muffled sound is because it's removing a lot of loud 2khz+ frequencies and replacing with quieter ones
Title: Re: exhale - Open Source USAC encoder
Post by: 1337Rainboom on 2022-08-19 10:35:47
It's probably just the distortion I'm hearing and not actually something weird going on with the stereo imaging but... yeah, it just sounds "wider" to me than the uncompressed file
I'd still pick Exhale over FDK, Apple and Opus... Opus adds way too much noise and what it does to the very low frequencies is baffling (multiplies the volume), FDK has horrible ringing due to SBR kicking in really soon, Apple is really broken up.. Exhale doesn't have the issues of FDK or Apple so even with the slight distortion, I'd say it's the best
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2022-08-20 12:00:16
It's probably just the distortion I'm hearing and not actually something weird going on with the stereo imaging but... yeah, it just sounds "wider" to me than the uncompressed file
Well observed. At low bit-rates and low frequencies, this may indeed happen, since there's a lot of quantization noise which may not be the same in both channels. At higher frequencies, I integrated a stereo image narrowing into exhale which should counteract this.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: 1337Rainboom on 2022-08-20 21:04:29
Could be it, maybe
I've found c and d to be the best lower bitrate presets, b everything is a bit too broken up, d has a lot more high frequency detail and sounds slightly less "underwater" to me but c isn't bad
Title: Re: exhale - Open Source USAC encoder
Post by: 1337Rainboom on 2022-08-23 02:11:11
I'm having some... strange behavior...
I took about 17 seconds of audio for a sample... but then I wanted a couple seconds cut off at the end so saved another sample that is about 15 seconds.. but I encoded both... the artifacting is in different areas...
on the 17 second sample, one of the loudest clicks is at about 0:02.. but I hear it in multiple areas... on the 15 second sample, the click at 0:02 is gone... but I hear some in other areas (like at 0:13 I hear multiple clicks close together on both encodes)
Also, preset a - 54kb, preset b - 62kb, preset c - 66kb

I even hear clicks by preset g... although, it's very, very faint (I of course realize you generally shouldn't use SBR this high, it's just for testing)
I think these artifacts are similar to what I was experiencing with the other sample I posted?  Maybe it's due to SBR..
okay, I posted a section in the spectrogram where a click happens... seems to be a patch of noise it adds... still pretty strange.. especially since the artifacting is different on a sample that is 2 seconds longer with nothing changed but that the sample is longer...

Nah, not exclusive to SBR... I'm hearing clicks with SBR disabled 64kbps setting as well
It's just patches of noise it is encoding...
Title: Re: exhale - Open Source USAC encoder
Post by: 1337Rainboom on 2022-08-23 03:28:52
okay, it's possible I messed something up the first time because I just took the exact same audio sections again just to make sure and now the artifacts match up between the shorter and longer encode... so never mind, sorry
Title: Re: exhale - Open Source USAC encoder
Post by: 1337Rainboom on 2022-08-23 04:56:12
sorry for so many posts but I figured out the difference (and it's what I suspected might be it)

One I dragged the original FLAC into Audacity and selected the time I wanted and exported... the other I selected the time, opened a new Audacity window and pasted it in... that removes the metadata... so perhaps that's it?
By pasting in a new window, it somehow removes a click or two that I hear
HOWEVER, when I do the same method with both the shorter and longer sample, there is different artifacting I'm hearing now... one, there's a click within the first second of audio... the other there isn't... I don't know if it's the metadata messing with it or if compressing a different amount of audio changes what the encoder decides to do but...

wait, now I'm very confused... no wait... both had the metadata in them... when I tested again, metadata is still there...
I'm confusing myself.. I might figure this out tomorrow but for now I just need to be done
Title: Re: exhale - Open Source USAC encoder
Post by: 1337Rainboom on 2022-08-23 06:50:19
okay, I just did some quick testing.. I think it's Audacity
Seems to randomize something when you paste a section of audio into a new window (file size keeps changing very slightly).. I don't know if this is what is causing the differences but... yeah
Probably dithering or something
Dragging an audio file directly in, however, produces the exact same file size each time
But since the files I posted have metadata, I believe this means I did NOT copy a section and paste it into a new window.. so does seem like length of encoding DOES change what artifacts are caused where
It does seem like even the smallest changes can cause drastic artifacts in different areas.. I do wonder why these "clicks" happen... but... they do
Title: Re: exhale - Open Source USAC encoder
Post by: 1337Rainboom on 2022-08-24 20:16:43
Eh, I guess that just happens with audio compression sometimes.. I just compressed something with 80kbps Apple LC-AAC... literally sounds like fireworks going off in some areas XD
And even the TINIEST of changes I guess can cause DRASTIC differences, it appears
Also the audio sample isn't a typical sample.. it has a few tones with a lot of blank space in-between and frequency doesn't go very high
Still a little strange but if I knew what was happening I'm sure it'd make sense
I guess it's "quantization noise" and it can just spontaneously create a massive amount of noise when bitrate is starved
Sorry for the wall of text, if I could edit previous posts I would
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2022-08-24 20:30:16
Not sure I can follow everything you wrote, but thanks for clearing it up. Also note that, to avoid artifacts from, possibly, appearing at different time positions when cutting off leading samples of a waveform, you need to cut off an integer multiple of 2048 samples per channel. That's due to the (xHE-)AAC framing during encoding.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2022-09-12 19:41:25
Apple Books now accepts content encoded in xHE-AAC.
Title: Re: exhale - Open Source USAC encoder
Post by: 1337Rainboom on 2022-09-16 20:05:14
I've noticed Exhale adds echo noise a lot... I hear a noise kind of like clapping
With Apple and Opus, it's more like an "air" sound.. but with Exhale it's kind of like clapping
But a lot of encoders seem to be adding some form of noise
I think it's because there's a lot of notes that don't have much sound around them... and encoders really don't like that
Title: Re: exhale - Open Source USAC encoder
Post by: Gravitator on 2022-09-18 07:18:03
I think it's because there's a lot of notes that don't have much sound around them... and encoders really don't like that
I noticed this problem too > OPUS vs exhale vs Fraunhofer vs QAAС when trying to replicate 15kHz (https://hydrogenaud.io/index.php/topic,122132.0.html)


Title: Re: exhale - Open Source USAC encoder
Post by: 1337Rainboom on 2022-09-22 05:30:04
Yeah but that is SBR frequencies... not the same thing
the distortion I'm hearing is below the SBR frequency range
Also, oof, that 15khz tone sounds really quiet.. my ears suck.. in my right ear above 12.75khz volume starts dropping pretty quick and in my left ear 13.25khz
Title: Re: exhale - Open Source USAC encoder
Post by: AR45H on 2022-10-13 01:25:15
Hey,
Does anyone know of a way to view the spectrogram of xHE-AAC tracks?
Audition, Audacity, and Spek do not support it.
Title: Re: exhale - Open Source USAC encoder
Post by: soundping on 2022-10-13 02:07:25
Convert your xHE-AAC audio files to wav.
Title: Re: exhale - Open Source USAC encoder
Post by: AR45H on 2022-10-13 04:36:00
Thanks for the tip soundping. That works.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2022-10-17 19:40:21
I just committed a small change to exhale's CVBR modes f, g, and 5, 6, see https://gitlab.com/ecodis/exhale. The primary purpose is to remove some old macro-encapsulation code and to bring the average encoding bit-rates of those modes closer to the target rates (96, 108, 128, and 144 kbps, respectively, for stereo). Thanks very much to guruboolez for thorough checking of the encoding bit-rates, and for sharing the results in his public table (https://docs.google.com/spreadsheets/d/18lGNoBB0ZB2A4SGAw3_z-5L7gzl54MG3D_V7tf2jII8/edit#gid=1119089008). Encoding at the other modes hasn't changed at all since release 1.1.9.

Literally, this is a 1.1.9.2 sub-release, but you can also call it an exhale 1.2.0 beta release since I'll tag a final 1.2.0 release at the end of the year and the encoding results probably won't change anymore.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2022-10-19 12:35:59
exhale V1.2.0 beta1 compiles below:

www.rarewares.org/files/aac/exhale-V1.2.0-beta1-444a0062_x64.zip (https://www.rarewares.org/files/aac/exhale-V1.2.0-beta1-444a0062_x64.zip)

www.rarewares.org/files/aac/exhale-V1.2.0-beta1-444a0062_x86.zip (https://www.rarewares.org/files/aac/exhale-V1.2.0-beta1-444a0062_x86.zip)
Title: Re: exhale - Open Source USAC encoder
Post by: Brazil2 on 2022-10-19 15:52:22
exhale V1.2.0 beta1 compiles below
Thanks  :) 👍
Title: Re: exhale - Open Source USAC encoder
Post by: jarsonic on 2022-10-19 16:08:52
exhale V1.2.0 beta1 compiles below:

www.rarewares.org/files/aac/exhale-V1.2.0-beta1-444a0062_x64.zip (http://www.rarewares.org/files/aac/exhale-V1.2.0-beta1-444a0062_x64.zip)

www.rarewares.org/files/aac/exhale-V1.2.0-beta1-444a0062_x86.zip (http://www.rarewares.org/files/aac/exhale-V1.2.0-beta1-444a0062_x86.zip)

The tags for files encoded with this binary still list the tool as "exhale 1.1.9" fwiw. :)
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2022-10-19 16:11:47
the contents of 'version.h' in the code remain unchanged although the changes referred to above are implemented. Not really within my remit to change the version number. ;)
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2022-10-23 18:21:14
Yeah, I was still trying some speedups when I committed this, which I finished today. So here's a new commit (https://gitlab.com/ecodis/exhale/-/commit/9202dbcc) with updated 'version.h' for an official exhale 1.2.0 release candidate, including several code improvements (thanks again, jprjr and NetRanger!).

Changes since exhale 1.1.9, released one year ago:

More speedup might be possible with Visual Studio compiles (see macro SFB_QUANT_SSE in lib/quantization.h), but that's probably still suboptimal.

Please compile and test as usual.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2022-10-24 00:42:39
Errors when compiling from macOS:

/Users/christian/Downloads/exhale-master/src/lib/../../src/lib/quantization.cpp:13:5: error: macro expansion producing 'defined' has undefined behavior [-Werror,-Wexpansion-to-defined]
#if SFB_QUANT_SSE
    ^
/Users/christian/Downloads/exhale-master/src/lib/../../src/lib/quantization.h:29:29: note: expanded from macro 'SFB_QUANT_SSE'
#define SFB_QUANT_SSE (0 && defined (_MSC_VER))
                            ^
/Users/christian/Downloads/exhale-master/src/lib/../../src/lib/quantization.cpp:49:5: error: macro expansion producing 'defined' has undefined behavior [-Werror,-Wexpansion-to-defined]
#if SFB_QUANT_SSE
    ^
/Users/christian/Downloads/exhale-master/src/lib/../../src/lib/quantization.h:29:29: note: expanded from macro 'SFB_QUANT_SSE'
#define SFB_QUANT_SSE (0 && defined (_MSC_VER))
                            ^
/Users/christian/Downloads/exhale-master/src/lib/../../src/lib/quantization.cpp:226:6: error: macro expansion producing 'defined' has undefined behavior [-Werror,-Wexpansion-to-defined]
# if SFB_QUANT_SSE
     ^
/Users/christian/Downloads/exhale-master/src/lib/../../src/lib/quantization.h:29:29: note: expanded from macro 'SFB_QUANT_SSE'
#define SFB_QUANT_SSE (0 && defined (_MSC_VER))
                            ^
/Users/christian/Downloads/exhale-master/src/lib/../../src/lib/quantization.cpp:283:12: error: variable 'tempBitCount' set but not used [-Werror,-Wunused-but-set-variable]
  unsigned tempBitCount, tuple, is;
           ^
4 errors generated.
make[1]: *** [../../build/quantization.r.o] Error 1
make: *** [release] Error 2
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2022-10-24 00:57:25
Version 1.2RC (ARM, built on Oct 24 2022) compile without errors on Linux (64bit).
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2022-10-24 01:06:03
Errors when compiling from macOS:
Oops, thanks for testing! Can you please try again with the latest revision (https://gitlab.com/ecodis/exhale/-/commit/46ae72a)?

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2022-10-24 02:05:33
The latest revision (46ae72aa) is compiled without errors even on macOS.
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2022-10-24 08:29:57
exhale v1.2.0-RC-46ae72aa
Built on October 24, 2022
GCC 12.2.0 & CLANG 15.0.3

https://gitlab.com/ecodis/exhale/-/commits/master
Title: Re: exhale - Open Source USAC encoder
Post by: Eurobeat_fan on 2022-10-24 09:19:56
NetRanger is the goat, thank you for your builds!
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2022-10-24 09:46:46
exhale v1.2.0-RC1-46ae72aa
Built on October 24, 2022
Intel 2022.2 (LLVM)

www.rarewares.org/files/aac/exhale-v1.2.0-RC1-46ae72aa_x64.zip (https://www.rarewares.org/files/aac/exhale-v1.2.0-RC1-46ae72aa_x64.zip)

www.rarewares.org/files/aac/exhale-v1.2.0-RC1-46ae72aa_x86.zip (https://www.rarewares.org/files/aac/exhale-v1.2.0-RC1-46ae72aa_x86.zip)
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2022-10-24 21:20:17
exhale v1.1.9.1-4ef4bc3c
Built on June 30, 2022, GCC 12.1.0
with this build and preset 9 output files have avg bitrate ~128 kbps.
Argh, thanks for reminding me about this. This still happens with NetRanger's GCC compile of the 1.2.0 release candidate, so two things to mention here:


For the record: The last known good GCC compile for the Windows platform here on HA is this one (https://hydrogenaud.io/index.php/topic,118888.msg1006531.html#msg1006531) (exhale 1.1.9, compiled with GCC 11.2.0).

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: doccolinni on 2022-10-24 21:39:56
Argh, thanks for reminding me about this. This still happens with NetRanger's GCC compile of the 1.2.0 release candidate, so two things to mention here:

  • Please do not use NetRanger's GCC 12.2.0 compile since that still has the high-bit-rate issue reported here (https://hydrogenaud.io/index.php/topic,118888.msg1010523.html#msg1010523)! Use his CLANG 15.0.3 binaries or John's Intel 2022 binaries instead.
  • I submitted a corresponding issue #26 (https://gitlab.com/ecodis/exhale/-/issues/26) on GitLab, summarizing the issue and asking for help. Again, experts on this wanted since I don't work with GCC/Msys2 myself, only VS.

I mean, since this is a known ongoing issue, perhaps @NetRanger should just not publish GCC builds of exhale until it's resolved?
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2022-10-24 23:06:02
Can you please try again with the latest revision (https://gitlab.com/ecodis/exhale/-/commit/46ae72a)?

version 1.2RC (x64, built on Oct 24 2022) compile without errors on macOS Ventura 13.0 (64bit).
Apple clang version 14.0.0 (clang-1400.0.29.102)
Target: x86_64-apple-darwin22.1.0
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2022-10-25 00:46:26
Thanks very much for the info, celona!

I mean, since this is a known ongoing issue, perhaps @NetRanger should just not publish GCC builds of exhale until it's resolved?
It seems it's been resolved very quickly on GitLab, thanks for C. Degawa. And NetRanger's compiles are always appreciated to identify such issues. Strange "signed/unsigned" interplay between GCC and MSYS2 was the cause, it seems, and not really exhale's fault, but oh well, rewrote one line of code anyway. NetRanger, feel free to give it another try with GCC 12.2.0 and the new revision (https://gitlab.com/ecodis/exhale/-/commit/c0fe486c).

(Note to myself:: don't forget to mention the fix of issue #26 in the release notes before tagging the final 1.2.0 release!)

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2022-10-25 01:16:44
exhale v1.2.0-RC2-c0fe486c
Built on October 25, 2022
GCC 12.2.0 & CLANG 15.0.3

https://gitlab.com/ecodis/exhale/-/commits/master
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2022-10-25 09:49:47
Tested the newly compiled GCC exhale binary on a few files now and it looks fine. Rather big change after the latest commit.

Great work on the quick fix. :)
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2022-10-25 10:12:26
exhale v1.2.0-RC2-c0fe486c
Built on October 25, 2022
Intel 2022.2 (LLVM)

https://www.rarewares.org/files/aac/exhale-v1.2.0-RC2-c0fe486c_x64.zip (https://www.rarewares.org/files/aac/exhale-v1.2.0-RC2-c0fe486c_x64.zip)

https://www.rarewares.org/files/aac/exhale-v1.2.0-RC2-c0fe486c_x86.zip (https://www.rarewares.org/files/aac/exhale-v1.2.0-RC2-c0fe486c_x86.zip)
Title: Re: exhale - Open Source USAC encoder
Post by: iwod on 2022-10-29 18:20:13
Not sure if this has been answered / asked before.
I am wondering if Exhale could theoretically be extended to encode AAC-LC files at high bitrate ( 200Kbps )?  On the assumption there would be overlap between xhe-AAC and AAC-LC making this easier.

The reason I asked is because we currently lack high quality AAC-LC encoder that is truly open source.
Title: Re: exhale - Open Source USAC encoder
Post by: jensend on 2022-10-29 22:03:05
Even beyond the "theoretically," I'm puzzled: what do you hope that would accomplish?

FDK-AAC is a high quality AAC-LC encoder and is open source.

There are two issues with its license. It contains code that makes use of patented techniques, and it does not come with a grant of any patent licensing. (It explicitly denies granting any such rights, rather than just not including any patent grant as most pre-GPL3 licenses did.)

These make its use in many circumstances legally questionable, and have led some linux distributions etc to call it non-free.

While LC-AAC patents have generally expired, getting a 'patent-free FDK-AAC for LC' may not be as simple as ripping out HE-AAC and HE-AACv2 code. It could take some very careful IP review. Lawyers lawyers lawyers.

Exhale's license has exactly the same problems. xHE-AAC is quite heavily patented. Exhale uses patented techniques and explicitly states that it doesn't/can't give you the right to use those patented techniques.

xHE-AAC is different enough from its predecessors that turning it into an LC encoder, and trying to get rid of patented techniques, would involve radical change. And then you'd still need the lawyers.

(CR Helmrich did have the sense to base his license on a standard license, where AFAIK those responsible for FDK-AAC didn't. But I don't think people object on the basis of any of the rest of FDK-AAC's license text. Yes, it says you can't charge for a copyright license, but that's not actually contravening the Debian Free Software Guidelines or whatever because it doesn't say you can't sell the software, just that you can't charge for a copyright license.)
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2022-12-10 10:20:10
So, I tagged the final 1.2.0 release of exhale, see https://gitlab.com/ecodis/exhale/-/releases. If you don't have any issues with exhale 1.1.9, you don't need to re-encode your audio files. This is mainly a bugfix and code stabilization release, with a major version number switch because the API changed a little. The audio quality improvement at ~128 kbps non-SBR and ~96 kbps SBR is very small on average and hardly noticeable.

exhale version 1.2.0 (December 2022)

Changes since version 1.1.9 from December 2021:

Not sure if this has been answered / asked before.
I am wondering if Exhale could theoretically be extended to encode AAC-LC files at high bitrate ( 200Kbps )?  On the assumption there would be overlap between xHE-AAC and AAC-LC making this easier.
Theoretically yes, but it's still quite a lot of work, see also post number 9 (https://hydrogenaud.io/index.php/topic,118888.msg980837.html#msg980837) in this thread. For that reason it's not on my To-Do list.

Happy end-of-year holidays, everyone!

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2022-12-10 11:18:19
Updated compiles at Rarewares. :)
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2022-12-10 11:27:13
exhale v1.2.0-cfbcd5b7
Built on December 10, 2022, GCC 12.2.0

https://gitlab.com/ecodis/exhale/-/releases/v1.2.0
Title: Re: exhale - Open Source USAC encoder
Post by: korth on 2023-01-05 16:53:55
One or more of the messages of this topic have been moved to Other Lossy Codecs (https://hydrogenaud.io/index.php?board=32.0) - https://hydrogenaud.io/index.php?topic=123519.0
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2023-05-06 19:56:36
exhale v1.2.0-cfbcd5b7
Built on May 06, 2023, GCC v13.1.0
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2023-07-14 10:29:03
fyi, a relatively minor issue was identified last week and a fix pushed a few moments ago along with commit https://gitlab.com/ecodis/exhale/-/commit/e796ab6a.

For details see this thread (https://hydrogenaud.io/index.php/topic,124414.0.html). When making binaries, please call this a 1.2.0.1 sub-release since I'll tag it like that on the weekend and since the changes are so few. Planning only annual releases now, I'll make a "more official" 1.2.1 release in December. Maybe some more issues have popped up by then.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2023-07-14 14:40:20
Updated compiles on Rarewares suitably tagged. :)
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2023-07-14 19:47:39
exhale v1.2.0.1-e796ab6a
Built on July 14, 2023, GCC 13.1.0

https://gitlab.com/ecodis/exhale/-/commits/master
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2023-08-30 19:10:09
fyi, I just committed a bit of test code* to exhale's Git repository. Since that code is disabled by default, there is no need for recompiled binaries.

* In case you're interested what I did here: I added this code to verify that exhale's quantization works as efficiently as desired... which it does in the vast majority of frames. To do so, I bypassed exhale's psychoacoustic model, making exhale operate in a manner which can more easily be evaluated using SNR measurements. Note that, when setting macro #define EE_MORE_MSE 10 in source file exhaleEnc.h, then recompiling, and calling the exhale command-line tool as exhale(.exe) 9 n 99 input.wav output.m4a, high-rate encodings similar to what FSLAC (https://hydrogenaud.io/index.php/topic,122390.0.html) produces are possible, but at a lower bit-rate.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: celona on 2023-09-27 09:44:52
I compiled Exhale for Linux ISA RISC-V 64, you can find it here:
http://81.56.4.34:7438/share/x4pYfC1S2x2ll5YW/exhale.zip

Once the program is launched, an x64 architecture is reported. I'll leave you the output below for any corrections.

  ---------------------------------------------------------------------
 | exhale - ecodis extended high-efficiency and low-complexity encoder |
 |                                                                     |
 | version 1.2.0 (x64, built on Sep 27 2023) - written by C.R.Helmrich |
  ---------------------------------------------------------------------

 Copyright 2018-2023 C.R.Helmrich, project ecodis. See License.htm for details.

 This software is made available under the exhale Copyright License and comes
 with ABSOLUTELY NO WARRANTY. This software may be subject to other third-party
 rights, including patent rights. No such rights are granted under this License.

 Usage:   exhale preset [inputWaveFile.wav] outputMP4File.m4a

 where

 preset   =  # (0-9)  low-complexity ISO/MPEG-D Extended HE-AAC at 16*#+48 kbit/s
         (a-g)  low-complexity Extended HE-AAC using eSBR at 12*#+36 kbit/s

 inputWaveFile.wav  lossless WAVE audio input, read from stdin if not specified

 outputMP4File.m4a  encoded MPEG-4 bit-stream, extension should be .m4a or .mp4


 Notes:   The above bit-rates are for stereo and change for mono or multichannel.


  ---------------------------------------------------------------------

I suggest the following lines for the output:
| version 1.2.1 (32 bit, built on 20230927) - written by C.R.Helmrich |
| version 1.2.1 (64 bit, built on 20230927) - written by C.R.Helmrich |
| version 1.2.1 (ARM 32, built on 20230927) - written by C.R.Helmrich |
| version 1.2.1 (ARM 64, built on 20230927) - written by C.R.Helmrich |
| version 1.2.1 (RISC-V, built on 20230927) - written by C.R.Helmrich |

  ---------------------------------------------------------------------

From actual exhaleApp.cpp code:

fprintf_s (stdout, " |                                                                     |\n");
#if defined (__arm__) || defined (__aarch64__) || defined (__arm64__)
  fprintf_s (stdout, " | version %s.%s%s (ARM, built on %s) - written by C.R.Helmrich |\n",
#elif defined (_WIN64) || defined (WIN64) || defined (_LP64) || defined (__LP64__) || defined (__x86_64) || defined (__x86_64__)
  fprintf_s (stdout, " | version %s.%s%s (x64, built on %s) - written by C.R.Helmrich |\n",
#else // 32-bit OS
  fprintf_s (stdout, " | version %s.%s%s (x86, built on %s) - written by C.R.Helmrich |\n",
#endif
             EXHALELIB_VERSION_MAJOR, EXHALELIB_VERSION_MINOR, EXHALELIB_VERSION_BUGFIX, __DATE__);
  fprintf_s (stdout, "  ---------------------------------------------------------------------\n\n");
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2023-09-29 13:24:51
Thanks for testing this! I'm reluctant to change the exhaleApp header text at this late stage, but can you please try the following change and tell me whether, after recompiling this on RISC-V, the garbage text disappears?

In file src/app/exhaleApp.cpp, change lines 60-62 to:

#if defined (__riscv) || defined (__riscv__) // coloring not interpreted on RISC-V
#define EXHALE_TEXT_INIT ""
#define EXHALE_TEXT_BLUE ""
#define EXHALE_TEXT_PINK ""
#else
#define EXHALE_TEXT_INIT "\x1b[0m"
#define EXHALE_TEXT_BLUE "\x1b[36m"
#define EXHALE_TEXT_PINK "\x1b[35m"
#endif

Thanks,

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2023-09-29 19:51:33
exhale v1.2.0.1-4c5a301d
Built on September 29, 2023, CLANG v17.0.1

https://gitlab.com/ecodis/exhale/-/commits/master
Title: Re: exhale - Open Source USAC encoder
Post by: Octocontrabass on 2023-09-29 19:52:56
// coloring not interpreted on RISC-V
The garbage text is from using a terminal that doesn't understand those escape sequences, it has nothing to do with RISC-V.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2023-09-29 21:08:20
Ah, good to know. Thanks for the clarification.

I committed a modified version of the code above, where users like celona can change line 60 as explained in the (new) comment.

Also worked some more on last month's test code* (see above). Remember, none of this stuff changes exhale's default behavior, so no need for recompiles or reencodings.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2023-10-01 17:29:51
exhale v1.2.0.1-0b683be9
Built on October 01, 2023, GCC v13.2.0

https://gitlab.com/ecodis/exhale/-/commits/master
Title: Re: exhale - Open Source USAC encoder
Post by: agentt on 2023-10-25 18:02:31
is possible 9 mode be 224/256 kbps? is it worth it?
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2023-12-20 13:05:21
No, not worth it, there are other AAC encoders providing at least the same audio quality at 192 kbps and above.

Regarding exhale and high bit-rates: I did identify two rare issues during the last weeks and (hopefully) fixed them this morning, so here's a new release candidate. Please compile, give it a test, and report back any warnings/errors. I'm planning to tag this as the final release on the weekend.

exhale version 1.2.1 (December 2023)

Changes since version 1.2.0 from December 2022:

Happy end-of-year holidays, everyone!

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: Thundik81 on 2023-12-20 18:05:04
Thanks a lot!
Could you also create a new release? (https://gitlab.com/ecodis/exhale/-/releases)
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2023-12-21 14:50:47
Oops, some strange bit-rate bloating going on at the lower-rate presets with this release candidate. I'll update this post once I've fixed that regression.

Fixed as part of Git commit b17f659c. Now my lower-preset encodings decode almost bit-identically to those made with exhale release 1.1.9, which is good... and the higher presets are still bugfixed, which is even better.

I'll tag (and release) this new version as v1.2.1 tomorrow, assuming nothing else pops up.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: NetRanger on 2023-12-22 21:12:45
exhale v1.2.1-b17f659c
Built on December 22, 2023, GCC v13.2.0

https://gitlab.com/ecodis/exhale/-/commits/master
https://gitlab.com/ecodis/exhale/-/releases
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2023-12-23 08:29:20
exhale v1.2.1-b17f659c compiles now at Rarewares. The "BA_MORE_CBR" variants will follow when I am able. (I am currently away from home until 16 January.) :)

Happy holidays to all.
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2023-12-26 09:55:26
The "BA_MORE_CBR" variants added as of 2023-12-26.
Title: Re: exhale - Open Source USAC encoder
Post by: Ziengaze on 2024-01-12 12:06:40
Quick playback question: I'm compiling ffmpeg with libfdk_aac support and while playing exhale encoded files the output volume is way too low. Does anyone know what the problem could be?
Title: Re: exhale - Open Source USAC encoder
Post by: atomicthumbs on 2024-01-28 18:21:45
Is it expected behavior for Apple's "Music.app" to refuse to play AAC files encoded with Exhale? I assumed it'd work because Core Audio supports USAC, but it doesn't seem to want to.
Title: Re: exhale - Open Source USAC encoder
Post by: Kraeved on 2024-02-25 02:56:15
Of all lossless and lossy audio codecs presented on this forum today, exhale is the most difficult for me to use. Its help screen mentions the author twice, says a lot about the license, there are even a few colors, but the essence of how to use it is barely designed for ordinary users. For example, I have FLAC 48 kHz 24 bit of Vertigo heroes (Part I) (https://www.youtube.com/watch?v=0g8TqOp8OJ4) by a famous perfectionist Boris Blank and want to compress it into a transparently sounding USAC file. Let's see…

Code: [Select]
 preset =  # (0-9)  low-complexity ISO/MPEG-D Extended HE-AAC at 16·#+48 kbit/s
            (a-g)  low-complexity Extended HE-AAC using eSBR at 12·#+36 kbit/s

Err… What? Aggrrhh! And then ogg -q8 or qacc without flags at all comes to rescue.
Title: Re: exhale - Open Source USAC encoder
Post by: Octocontrabass on 2024-02-25 04:04:37
Err… What?
The preset is a single number (or letter) with no prefix. Much like how you use "oggenc -q8" you might use "exhale 8".
Title: Re: exhale - Open Source USAC encoder
Post by: Kraeved on 2024-02-25 12:40:28
@Octocontrabass, indeed, “it's a single number of letter”, but there are

Code: [Select]
$ powershell -c "(0..9 + [char]'a'..[char]'g').length"
17
17 (!) presets to choose from without any intuitive guidance other than “check with your ears”. And why not 7 or 27? It's like coming into the airplane's cockpit and trying out each button to find out which one controls the landing gear (https://www.youtube.com/watch?v=paKC6MTvp7Q).

Expressions such as “low-complexity ISO/MPEG-D Extended HE-AAC” and “low-complexity Extended HE-AAC using eSBR” sound like they are taken from or meant for an application for RFC, so technical and bureaucratic is the language.

The tool is usually created to solve typical tasks. In this case, one of them is music compression. Accordingly, in addition to describing options in a more meaningful (https://wiki.hydrogenaud.io/index.php?title=LossyWAV#Quality_presets) way so that users do not have to ask again (https://hydrogenaud.io/index.php/topic,120827.0.html) and again (https://sound.stackexchange.com/questions/48596/flac-compression-options-unclear-exhaustive-model-search-qlp-coeff-precisi), I believe there should be a recommendation (https://www.wavpack.com/wavpack_doc.html#usage) based on the author's experience and/or a consensus of a community of enthusiasts.
Title: Re: exhale - Open Source USAC encoder
Post by: C.R.Helmrich on 2024-02-25 17:20:34
Sorry, but the following information has been around for several years now:

https://gitlab.com/ecodis/exhale#usage (provides a command-line example)

https://gitlab.com/ecodis/exhale/-/wikis/faq#how-does-the-bit-rate-mode-of-the-exhale-application-or-library-work

IgorC actually provided the bases of these links in the very first post of this thread.

You can also call exhale.exe # inputFile.wav outputFile.m4a when you're not sure. Consider this mode a recommendation.

Finally, as has been discussed several times on this forum, "transparently sounding" encoding is an attribute which depends on a user's hearing capabilities and the audio content being encoded.

I don't see how, apart from specifying an input and output file, it can get much simpler than specifying a single character. If someone doesn't understand possible other parameters, (s)he probably shouldn't be using them.

Chris
Title: Re: exhale - Open Source USAC encoder
Post by: jaybeee on 2024-02-28 11:14:20
I'm certainly no n00b lol, but I simply cannot get foobar to play exhale files; gives me the Unsupported format or corrupted file.

I've read and followed the guidance at the Exhale wiki about corrupt files in foobar (https://gitlab.com/ecodis/exhale/-/wikis/faq#i-get-corrupted-files-when-encoding-using-exhale-via-foobar2000-why), but still no joy.

I've created Exhale encoded files using:
1. the foobar converter editing screen
2. the foobar commandline editing screen
3. cmd line with exhale.exe (via rarewares and via netranger's compile)

Files are successfully created. This is what MediaInfo reports (https://snipboard.io/xyLrIu.jpg) (that file is the cmdline created one). I noticed MediaInfo reports some "conformance errors" - unsure if that's expected or related.

I know there is the foo_pd_aac (https://www.foobar2000.org/components/view/foo_pd_aac) component that Kode54 created, but that only works on win 32-bit (I'm Win10 64-bit) - and anyway, it thought foobar could play these files without that component now (tried v2.1 and now just tried v2.2 preview 2024-02-19).

I was kind of loathed to report this as I know it's been an issue before, but I simply cannot figure this one out, so if it is an easy issue then others may find it useful to see what a silly they're being like me lol.
Title: Re: exhale - Open Source USAC encoder
Post by: john33 on 2024-02-28 11:35:37
You'll find the 64 bit version at the foot of this page: https://foobar.hyv.fi/ (https://foobar.hyv.fi/)
Title: Re: exhale - Open Source USAC encoder
Post by: jaybeee on 2024-02-28 11:49:14
You'll find the 64 bit version at the foot of this page: https://foobar.hyv.fi/ (https://foobar.hyv.fi/)
I knew it would be simple! Thanks john33

Damn, I really thought foobar was able to play these files "out of the box" now.

I think that component (and the 32-bit version) could be linked to in the wiki @C.R.Helmrich
Title: Re: exhale - Open Source USAC encoder
Post by: DanDanV on 2024-03-17 21:25:31
Can you kindly explain me, how exactly ReplayGain works together with MP4 DRC? I'm not too clear about these two things. Should I write ReplayGain tags after encoding with exhale?