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 302356 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: exhale - Open Source USAC encoder

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

Re: exhale - Open Source USAC encoder

Reply #1051
Sorry, Ziengaze, I cannot reproduce the phenomenon you're observing. All Windows compiles I tried (John's from post 1025 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
If I don't reply to your reply, it means I agree with you.

Re: exhale - Open Source USAC encoder

Reply #1052
Built on windows 10 21h1 using msys2 with gcc 11.3.0.

Re: exhale - Open Source USAC encoder

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

Re: exhale - Open Source USAC encoder

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

Re: exhale - Open Source USAC encoder

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

Re: exhale - Open Source USAC encoder

Reply #1056
In the early days of exhale development, someone already mentioned this in FFmpeg 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, requires such a two-step approach, as shown in Sec. 4. Plugin Usage of their User Guide.

Chris
If I don't reply to your reply, it means I agree with you.

Re: exhale - Open Source USAC encoder

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

Re: exhale - Open Source USAC encoder

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


 

Re: exhale - Open Source USAC encoder

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

Re: exhale - Open Source USAC encoder

Reply #1061
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:

  • bsSamplePeakLevel
  • methodDefinition
  • methodValue
  • measurementSystem
  • reliability

Re: exhale - Open Source USAC encoder

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

Re: exhale - Open Source USAC encoder

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

Re: exhale - Open Source USAC encoder

Reply #1064
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:

  • bsSamplePeakLevel = 672, for -1 dBFS
  • methodDefinition = 1, see constant EA_LOUD_INIT
  • methodValue = 139, for -23 LUFS
  • measurementSystem = 2, part of value 11 in code
  • reliability = 3, part of value 11 in code

Chris
If I don't reply to your reply, it means I agree with you.

Re: exhale - Open Source USAC encoder

Reply #1065
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?

Re: exhale - Open Source USAC encoder

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

Re: exhale - Open Source USAC encoder

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


Re: exhale - Open Source USAC encoder

Reply #1069
Small update pushed to Gitlab 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. 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!

Re: exhale - Open Source USAC encoder

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


Re: exhale - Open Source USAC encoder

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