Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: exhale - Open Source USAC encoder (Read 304457 times) previous topic - next topic
0 Members and 4 Guests are viewing this topic.

Re: exhale - Open Source USAC encoder

Reply #650
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
If I don't reply to your reply, it means I agree with you.

Re: exhale - Open Source USAC encoder

Reply #651
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


Re: exhale - Open Source USAC encoder

Reply #653
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
If I don't reply to your reply, it means I agree with you.

Re: exhale - Open Source USAC encoder

Reply #654
Test versions: exhale_ad888151-Linux-armv7l.bz2 - 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 - after.txt.

Re: exhale - Open Source USAC encoder

Reply #655
Intel compiles of: exhale-v1.1.4-RC1-ab91fd8f
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
• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data

Re: exhale - Open Source USAC encoder

Reply #656
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.

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

    AiZ

Re: exhale - Open Source USAC encoder

Reply #657
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’s HE-AAC v2 (SBR+PS) output with -p 29 -m 5 switches (or -vbr 5 in terms of FFMPEG’s libfdk_aac).
• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data

Re: exhale - Open Source USAC encoder

Reply #658
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
If I don't reply to your reply, it means I agree with you.

Re: exhale - Open Source USAC encoder

Reply #659
I attached FLAC, Exhale’s output with g switch, and FDK’s HE-AAC v2 (SBR+PS) output with -p 29 -m 5 switches (or -vbr 5 in terms of FFMPEG’s libfdk_aac).
You do realize that those settings don't make any sense and actually produce inferior quality, right?

Re: exhale - Open Source USAC encoder

Reply #660
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.

Re: exhale - Open Source USAC encoder

Reply #661
I attached FLAC, Exhale’s output with g switch, and FDK’s HE-AAC v2 (SBR+PS) output with -p 29 -m 5 switches (or -vbr 5 in terms of FFMPEG’s libfdk_aac).
You do realize that those settings don't make any sense and actually produce inferior quality, right?

Broadcasters use similar settings and ordinary listeners are curious about xHE-AAC vs HE-AAC v2 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.
• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data

Re: exhale - Open Source USAC encoder

Reply #662
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

 

Re: exhale - Open Source USAC encoder

Reply #663
Broadcasters use similar settings and ordinary listeners are curious about xHE-AAC vs HE-AAC v2 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.

Re: exhale - Open Source USAC encoder

Reply #664
...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)

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.

Re: exhale - Open Source USAC encoder

Reply #665
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."


Re: exhale - Open Source USAC encoder

Reply #667
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

Re: exhale - Open Source USAC encoder

Reply #668
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
If I don't reply to your reply, it means I agree with you.

Re: exhale - Open Source USAC encoder

Reply #669
@C.R.Helmrich I have a small suggestion to improve the clarity of Exhale usage on the Exhale github page / 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.
 :)

Re: exhale - Open Source USAC encoder

Reply #670
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.
• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data

Re: exhale - Open Source USAC encoder

Reply #671
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.

Re: exhale - Open Source USAC encoder

Reply #672
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 and Total Commander to name a few). Lame works there as well, Exhale does not.
• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data

Re: exhale - Open Source USAC encoder

Reply #673
@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..

Re: exhale - Open Source USAC encoder

Reply #674
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. ;-)
lame --abr 288 -f --lowpass 17 (+ mp3gain@92 dB)