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

Re: exhale - Open Source USAC encoder

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

Re: exhale - Open Source USAC encoder

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

Re: exhale - Open Source USAC encoder

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

Re: exhale - Open Source USAC encoder

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

Re: exhale - Open Source USAC encoder

Reply #1029
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, 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.

Re: exhale - Open Source USAC encoder

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

Re: exhale - Open Source USAC encoder

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

Re: exhale - Open Source USAC encoder

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


Re: exhale - Open Source USAC encoder

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

Re: exhale - Open Source USAC encoder

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

Re: exhale - Open Source USAC encoder

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

Re: exhale - Open Source USAC encoder

Reply #1037
To decode with ffmpeg you need to tell it to use fdkaac. ffmpeg -c:a libfdk_aac -i <input> <output>.

Re: exhale - Open Source USAC encoder

Reply #1038
Thank you Case.

That fixed the issue I was having.  I really appreciate the help. 

Re: exhale - Open Source USAC encoder

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

Re: exhale - Open Source USAC encoder

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

Re: exhale - Open Source USAC encoder

Reply #1041
Has the encoding limit for AAC been reached?


Re: exhale - Open Source USAC encoder

Reply #1043
Should we expect new compression methods? It looks like the OPUS has already hit the wall. Video coders continue to improve.

 

Re: exhale - Open Source USAC encoder

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