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

Re: exhale - Open Source USAC encoder

Reply #1200
FFmpeg now implements a native xHE-AAC decoder:
https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/eee5fa08083c1df6d0210bf215b658bc3017f98d

Thanks for sharing this. It's actually great news.  :)

When FFmpeg xHE-AAC decoder will be ready we will see wide native support of this format in software players, as foobar2000, and other apps.

It's a true beginning of xHE-AAC support in internet and streaming.  :)

Re: exhale - Open Source USAC encoder

Reply #1201
FFmpeg now implements a native xHE-AAC decoder
At last! Thanks for this really great news!
Wavpack Hybrid: one encoder for all scenarios
WavPack -c4.5hx6 (44100Hz & 48000Hz) ≈ 390 kbps + correction file
WavPack -c4hx6 (96000Hz) ≈ 768 kbps + correction file
WavPack -h (SACD & DSD) ≈ 2400 kbps at 2.8224 MHz

Re: exhale - Open Source USAC encoder

Reply #1202
Great news, indeed, but don't throw away Case's fdk-aac packet decoder for foobar2000 just yet. The new FFmpeg decoder (just tried it with the Windows ...git-essentials.7z binary from https://www.gyan.dev/ffmpeg/builds/) doesn't do SBR or any other low-bit-rate technology yet, doesn't do gapless playback via trailing-sample cropping according to the edit-list data, doesn't do loudness control according to the DRC data, and still has a small low-frequency glitch in some transient stereo frames. Example for reproduction attached. More details will follow once I can narrow the issue down further.

Update: It seems that decoder also has the same issue that one of Apple's USAC decoders once had, first reported by Celona here. But since exhale was modified in late 2020 so as not to trigger that decoder issue, that's not too problematic in my view. But there may be other USAC encoders out there, of course.

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

Re: exhale - Open Source USAC encoder

Reply #1203
OK, in the above example bitstream, I tracked the issue down to the entropy decoding of a single spectral coefficient, the first coefficient in the eighth transform (win == 7) of the right channel (side of M/S coded pair) of the third frame in the file having window_sequence == EIGHT_SHORT_SEQUENCE. The magnitude encoded by exhale is 13 but the magnitude decoded by FFmpeg seems to be something else, i.e. different from the magnitude decoded by the fdk-aac packet decoder. Strangely, when I use a debugger to change the magnitude to e.g. 14 (or something else) during encoding, FFmpeg seems to produce the correctly decoded output, i.e. the same output as the fdk-aac packet decoder. Attached both bitstreams along with the decoded waveforms for each bitstream. Notice the difference in the waveforms around sample time-offset 5600 (0.127 sec).

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

 

Re: exhale - Open Source USAC encoder

Reply #1204
No ffmpeg devs visit this obscure forum, contact them on mailing list/github/irc instead.
Please remove my account from this forum.

Re: exhale - Open Source USAC encoder

Reply #1205
So you're not an FFmpeg dev? Anyway, it seems that 3 of the 6 issues I mentioned above are being worked on already, since at least yesterday (see FFmpeg patches 1/6, 3/6, 6/6). Which is great! Maybe this forum is not as obscure as you wish...

And the gapless playback enforcement could be realized on the player side (e.g., as currently done in foobar2000), I guess. So that issue report is more of a note to Peter and other player developers.

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

Re: exhale - Open Source USAC encoder

Reply #1206
Yes, no more ffmpeg dev. This forum is obscure, that is simple fact, nothing to do with my wishing.
To get fixed all the remaining points contact them, and btw ask them do they follow HA forum.
Please remove my account from this forum.

Re: exhale - Open Source USAC encoder

Reply #1207
how does exhale compare at transparency bitrates against aac-lc or opus? (higher than 128 kbps) is it optimised for this?
At which preset does it reach transparency?


Re: exhale - Open Source USAC encoder

Reply #1209
Name of encoders not provided.
Please remove my account from this forum.



Re: exhale - Open Source USAC encoder

Reply #1212
There is a small problem that has not been solved
Although interesting, excuse my asking, but why do you use Exhale for 5.1 multichannel encoding at 560-953 kbps?
Isn't Exhale a codec optimised for stereo at very low bitrates? You can encode 5.1 E-AC3 at 640kbps for free with ffmpeg and have full compatibility. Where do you play 5.1 MPEG-D USAC xHE-AAC content? Do recent tvs support it?

Since it is a test, the purpose is to find possible problems, not just to find them in common situations.
It's just a test, don't worry about it


I'd like to know how did you encode five channels. Exhale.exe documentation is only for stereo wav, as long as I see.

Re: exhale - Open Source USAC encoder

Reply #1213
Quote
I'd like to know how did you encode five channels. Exhale.exe documentation is only for stereo wav, as long as I see.
Autoresponse: Sorry, I didn't fully read documentation.
It can encode 5.1 wav. I did some tests at 480 kps. By curiosity, my 2022 Samsung S95B tv plays xHE stereo and wav 5.1, but not xHE multichannel. On the pc it plays well with mpv. My tv plays multichannel with AAC-LC, but it does not with opus (haven't been able to). I don't know if it has do to with channel layout. AAC 5.1 layout is C L R Ls Rs LFE. WAV is L R C LFE Ls Rs.