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

Re: exhale - Open Source USAC encoder

Reply #1150 –
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.

Re: exhale - Open Source USAC encoder

Reply #1151 –
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) 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.
• 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 #1153 –
@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.

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 way so that users do not have to ask again and again, I believe there should be a recommendation based on the author's experience and/or a consensus of a community of enthusiasts.
• 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 #1154 –
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
If I don't reply to your reply, it means I agree with you.

Re: exhale - Open Source USAC encoder

Reply #1155 –
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, 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 (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 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.

Re: exhale - Open Source USAC encoder

Reply #1156 –
You'll find the 64 bit version at the foot of this page: https://foobar.hyv.fi/
 

Re: exhale - Open Source USAC encoder

Reply #1158 –
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?

Re: exhale - Open Source USAC encoder

Reply #1159 –
Hi,

I can't play any USAC 5.1 file.

According to official website, exhale's "objective is high quality mono, stereo, and multichannel coding at medium and high bit rates". And to FAQ, "For multichannel audio, the bit-rates increase accordingly". So multichannel is supposed to work.
I can indeed create an 5.1 file with foobar2000 and last exhale. But I can't play it:

Quote
Unable to open item for playback (Unsupported format or corrupted file):
"C:\-------\0005.m4a"

I tried with and without foo fdk aac packet decoder on foobar2000 v2.x, with many files: same issue.

A 30sec track is uploaded (flac and m4a/USAC).

Thanks :)

Re: exhale - Open Source USAC encoder

Reply #1160 –
The wikipedia page for xHE-AAC says it's meant for low-bitrate use and only mentions mono/stereo. The Fraunhofer's whitepaper also only talks about mono and stereo (apart from bottom of the paper mentionin multichannel related to DASH). Mainconcept also only talks about stereo audio in relation to xHE-AAC. These are all the specs I have been able to find.
Also Apple, Google and Windows 11 support xHE-AAC natively and none of these play the multichannel file.

Re: exhale - Open Source USAC encoder

Reply #1161 –
Quote from: guruboolez on
I can't play any USAC 5.1 file.
There's a difference between xHE-AAC (what you and Case are talking about) and USAC a.k.a. Extended HE-AAC (a format which partially overlaps with xHE-AAC). exhale is a USAC encoder, but I don't know of any publicly available USAC decoder capable of multichannel.

See also https://gitlab.com/ecodis/exhale/-/issues/25

Quote from: jaybeee on
I think that component (and the 32-bit version) could be linked to in the wiki @C.R.Helmrich
Good point, will do that. Thanks for the reminder.

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

Re: exhale - Open Source USAC encoder

Reply #1162 –
Why do you allow encoding multi channel files when they aren't even supposed to work?

Re: exhale - Open Source USAC encoder

Reply #1163 –
They are supposed to work! And actually do... with a proper USAC decoder. The USAC (non xHE-AAC) reference software decoder decodes 5.1 USAC files. It's not my fault, or my decision, that no such decoders are publicly available, but they might be privately available to some users of exhale.

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

Re: exhale - Open Source USAC encoder

Reply #1164 –
Thanks for the answer. If it's on the decoder side, I won't try further.
Funnily: the 5.1 m4a file is silently playable on my video player (MPC-BE) which doesn't support xHE-AAC but a common 2.0 file is rejected...

Personal life: I'm trying to get rid of most of my SACD (ISO: 2CH + MCH = ~4GB/album). 20 years after I bought my first SACD I still don't have any multichannel setting at home. I still have a small hope for get one in a far future  :P So I'm trying to keep a smaller lossy copy of the multichannel stream (DSD 5.0 with WV5 > 7000 kbps). I guess I'll stick with AAC or Opus.

Re: exhale - Open Source USAC encoder

Reply #1165 –
Ok, since it's not against specs I took the liberty to add experimental multichannel support to fdk-aac packet decoder.
I don't know if the FDK library is wrong or if exhale doesn't care about input, but the channel maps in encoded files seem to stay the same regardless of what channel maps the source WAVs have.

Re: exhale - Open Source USAC encoder

Reply #1166 –
Thanks Case! You're brilliant  8)  On my side, exhale's multichannel files now decode flawlessly (but I remind: I play them downsampled to stereo). I can't say if channel mapping is entirely correct.

Re: exhale - Open Source USAC encoder

Reply #1167 –
Note that exhale only knows channel map "6" from https://wiki.multimedia.cx/index.php/MPEG-4_Audio, and since exhale is primarily meant for mono and stereo (due to the above limitations of xHE-AAC decoders), I won't extend exhale's functionality here. MPEG-H Audio coding is more efficient for multichannel, anyway.

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

Re: exhale - Open Source USAC encoder

Reply #1168 –
Quote from: guruboolez on
I can't play any USAC 5.1 file.
0005.m4a

MediaInfo report:
Code: [Select]
Conformance warnings                     : 1
 UsacConfig                              : Yes
  General compliance                     : Extra zero bytes after the end of the syntax was reached (frames 0+84)

Conformance information                  : 2
 UsacLfeElement                          : UsacLfeElement support not implemented (frames 0.0+84.0+126)
 Crosscheck                              : Yes
  sbgp                                   : Yes
   roll_distance                         : MP4 sbgp is not present and this is an independent frame (IF), seeking is not optimal (frames 41+42+83+125+126)

With a button which is sending me to this page:
https://mediaarea.net/MoreInfo?mi=%7B%22creatingLibrary%22%3A%7B%22name%22%3A%22MediaInfoLib%22%2C%22version%22%3A%2224%2E03%22%7D%2C%22media%22%3A%7B%22track%22%3A%5B%7B%22Format%22%3A%22MPEG-4%22%7D%2C%7B%22Format%22%3A%22USAC%22%2C%22extra%22%3A%7B%22ConformanceWarnings%22%3A%7B%22UsacConfig%22%3A%7B%22GeneralCompliance%22%3A%22Extra%20zero%20bytes%20after%20the%20end%20of%20the%20syntax%20was%20reached%20%28frames%200%2B84%29%22%7D%7D%2C%22ConformanceInfos%22%3A%7B%22UsacLfeElement%22%3A%22UsacLfeElement%20support%20not%20implemented%20%28frames%200%2E0%2B84%2E0%2B126%29%22%2C%22Crosscheck%22%3A%7B%22sbgp%22%3A%7B%22roll_distance%22%3A%22MP4%20sbgp%20is%20not%20present%20and%20this%20is%20an%20independent%20frame%20%28IF%29%2C%20seeking%20is%20not%20optimal%20%28frames%2041%2B42%2B83%2B125%2B126%29%22%7D%7D%7D%7D%7D%5D%7D%7D

Re: exhale - Open Source USAC encoder

Reply #1169 –
Quote from: C.R.Helmrich on
Note that exhale only knows channel map "6" from https://wiki.multimedia.cx/index.php/MPEG-4_Audio, and since exhale is primarily meant for mono and stereo (due to the above limitations of xHE-AAC decoders), I won't extend exhale's functionality here. MPEG-H Audio coding is more efficient for multichannel, anyway.

Chris
Understood, but without the source having the channels remapped, doesn't that make the multichannel encoding worse than useless in most cases?

Re: exhale - Open Source USAC encoder

Reply #1170 –
I took a quick look at exhale sources and I don't see it doing anything to source WAV file channel order. If that's the case @john33 is absolutely correct and multichannel files encoded with it are quite broken, unless manually reordered to correct channel order.

@guruboolez - if this is the case, the component I linked above plays the channels in wrong order for valid files. I made it remap the library output based on exhale-created test files. That also explains why rear surround channel quality was so awful - it was encoded as LFE.

Edit: uploaded a new build that leaves channel order as it comes out from the decoder.

Re: exhale - Open Source USAC encoder

Reply #1171 –
@case: Thanks for the update and the warning  :)

Re: exhale - Open Source USAC encoder

Reply #1172 –
@Case , your site says compatible with fb2k 1.5+ but it fails to load on 1.6.17...

Quote
Failed to load DLL: foo_pd_aac.dll
Reason: Wrong version number; this component appears to have been built with a newer version of the foobar2000 SDK, please download latest version of foobar2000 in order to use it.

Re: exhale - Open Source USAC encoder

Reply #1173 –
Quote from: marc2k3 on
@Case , your site says compatible with fb2k 1.5+ but it fails to load on 1.6.17...
Thanks and sorry. This was using old and misconfigured SDK. Uploaded recompile made with the latest SDK and verified it to run on foobar2000 v1.5.x.

Re: exhale - Open Source USAC encoder

Reply #1174 –
As for decoder side, has anyone tried this?
https://github.com/Fraunhofer-IIS/mpeghdec

It seems to be based on the decoder part  of FDK-AAC but is updated to support MPEG-H.

https://github.com/Fraunhofer-IIS/mpeghdec/blob/main/src/libMpeghDec/include/aacdecoder_lib.h
The header says it supports MPEG-2/4 AAC, MPEG-D Audio(USAC), and MPEG-H Audio.

USAC config parser of FDK-AAC refuses channel_configuration > 2 here (maybe xHE-AAC restriction?):
https://github.com/mstorsjo/fdk-aac/blob/master/libMpegTPDec/src/tpdec_asc.cpp#L2148

In mpeghdec, the same function is updated to also support MPEG-H config and  the restriction  seems to be removed:
https://github.com/Fraunhofer-IIS/mpeghdec/blob/main/src/libMpegTPDec/src/tpdec_asc.cpp#L458