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

Re: exhale - Open Source USAC encoder

Reply #1200 –
Quote from: celona on
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 –
Quote from: celona on
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 –
Quote from: ha7pro on
Quote from: wyup on
Quote from: ha7pro on
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.

Re: exhale - Open Source USAC encoder

Reply #1214 –
Quote from: mycroft on
Yes, no more ffmpeg dev. This forum is obscure, that is simple fact...

It means we got lost in useless discussions, in my opinion, with ISO/IEC 23094-2 the game has literally changed and this is interesting for ffmpeg contributors. We certainly won't attract them by talking about what vinyl sounds like in 2024.

The idea of ​​the Italian co-authors to improve existing video codecs by reducing their complexity through a complementary encoder eliminated the need to produce different contents based on the media or for the required resolution. On the one hand, this satisfies an important request from content producers who do not want to duplicate their work because it generates costs, on the other hand, it reduces the friction that has existed up to now in introducing patented improvements.

So far we've been talking about video and its distribution, where does audio come into play? In fact, the new digital TV in Brazil and India will use MPEG-H for audio, and only optionally LC-AAC. In China, the scenario will be similar. In Europe there is an obstacle and it is the one that has limited the birth of European broadcasters until now, many different languages ​​are spoken.

Now imagine YouTube that in addition to keeping the audio in LC-AAC, HE-AAC and Opus for each video, has to do the same thing for multiple languages audio ​​and add subtitles in each language for the hearing impaired, in addition to the audio description of the scene for the visually impaired, etc. Well, this will become mandatory in Europe and someone will need to distribute the same content for HBBTV or DVB-I, i.e. also via the Internet, preferably without having to create different versions.

Perhaps the time has come to rethink what was done with MPEG-D USAC, to use two different encoders for speech and for the soundtrack and to move from the distribution of different tracks, a central one only for speech and a stereophonic one or in multiple channels with a differential encoder for the audio.

This is of great interest to those who work on ffmpeg, it would allow all their users to be able to play any content on any operating system, the old encoders would perform the same fallback role that SBC has in Bluetooth. It would also be a welcome thing for the patent holders, and also for the States that could start the umpteenth transition from DVB-T2 without having to subsidize the purchase of new decoders or TVs, because the fallback codec would always allow their use.

In Europe, the presence of a separate audio channel for speech (24 kbps would be enough even with the latest Opus), after decoding the stereo tracks, would allow the software to mix the voice into the user's language (the same as the graphical interface), and a layer with a differential encoder would allow the enjoyment of MPEG-H multichannel audio and higher quality.

Realistically, for many users and for many uses, even radio or online, in multiple languages ​​would be more useful than multi-channel audio delivered to an audience of listeners wearing headphones, and without beating around the bush, sales data say that this is the reality, few invest as in the past in purchasing amplifiers and speakers and even fewer spend more than in the past, this has already killed multi-channel systems that require a greater expense to obtain the same quality as a stereo system.

I would add that the voice in a separate track would make it easier both to automatically speech to texts using artificial intelligence and to translate them into other languages.

Re: exhale - Open Source USAC encoder

Reply #1215 –
Quote from: celona on
It means we got lost in useless discussions, in my opinion, with ISO/IEC 23094-2 the game has literally changed...
Well, in spirit that approach is exactly the same as the original SBR from 2002 - smart upsampling (or upscaling) of a low-resolution (frequency or spatially) compressed signal, using some extra side-information, which is added to the bitstream of that compressed signal. Do you expect this to be any more relevant than one of the new codecs out there in the longer term? And isn't that SBRish video codec patented as well? It certainly isn't free, is it?

Anyway, back to audio and FFmpeg: the issue of the new (half-)USAC decoder which I mentioned above still exists in the latest FFmpeg, despite the respective author of that decoder knowing about the issue...

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

Re: exhale - Open Source USAC encoder

Reply #1216 –
Why was the DRC made mandatory in this codec? Is there a way to disable it?

It's kinda strange that the codec decides which volume level is best whereas the original audio is already perfectly mastered. Please tell me I can somehow disable this setting so that the original volume of the source file is maintained.

Re: exhale - Open Source USAC encoder

Reply #1217 –
In the xHE-AAC "profile", it's mandatory, yes. But not in USAC/Extended HE-AAC, I think. It depends on the decoder available to you. In foobar2000 (all recent versions) or FFmpeg (upcoming 7.1 release), for example, you can disable it.

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

Re: exhale - Open Source USAC encoder

Reply #1218 –
Quote from: C.R.Helmrich on
In the xHE-AAC "profile", it's mandatory, yes. But not in USAC/Extended HE-AAC, I think. It depends on the decoder available to you. In foobar2000 (all recent versions) or FFmpeg (upcoming 7.1 release), for example, you can disable it.

Chris

Thank you! Also, I wanted to say another big Thank You for developing such an awesome codec. At 192 kbit/s it absolutely nails the transparency, crispness and airiness of the original high quality 24-bit/48Khz audio. I did some listening tests and while AAC-LC does seem to reproduce the complete audible frequency range at the same bitrate, somehow I feel the audio is overall a bit flat and lacks the "air" that is present in the original file and some microdetails as well. Whether it's subconsious or not, I'm not sure, but I feel the USAC-encoded audio sounds closer to the original - completely indistinguishable, to be exact. Not going to try to convince anyone, just my opinion!

I used the command you left earlier in this thread: "For 24 and 48.0 kHz input: exhale.exe 9 n 50 input.wav output.m4a".

While I understand that Opus is not worse than USAC, for my use case I need something different (but also cutting-edge) for the compabitility with .mp4 container for my custom-encoded videos. And so USAC it is!

Re: exhale - Open Source USAC encoder

Reply #1219 –
Quote from: Leo 69 on
At 192 kbit/s it absolutely nails the transparency, crispness and airiness of the original high quality 24-bit/48Khz audio. I did some listening tests and while AAC-LC does seem to reproduce the complete audible frequency range at the same bitrate, somehow I feel the audio is overall a bit flat and lacks the "air" that is present in the original file and some microdetails as well. ...
xHE-AAC vs LC-AAC
https://hydrogenaud.io/index.php/topic,120007.0.html
 

Re: exhale - Open Source USAC encoder

Reply #1220 –
Quote from: Leo 69 on
At 192 kbit/s it absolutely nails the transparency, crispness and airiness of the original high quality 24-bit/48Khz audio. I did some listening tests and while AAC-LC does seem to reproduce the complete audible frequency range at the same bitrate, somehow I feel the audio is overall a bit flat and lacks the "air" that is present in the original file and some microdetails as well.
[...]
but I feel the USAC-encoded audio sounds closer to the original - completely indistinguishable, to be exact.
Quote
Whether it's subconsious or not, I'm not sure,

Make no mistake, it is subconscious - and, as you're probably aware, folks here tend not to take such subjectivity at face value.
Even if backed up by listening audio tests' results, just the numbers would've sufficed.
How I stopped worrying and returned to loving lossy encoding again?
By listening to music, not the media it's on.

"União e reconstrução"

Re: exhale - Open Source USAC encoder

Reply #1221 –
To anyone wanting to listen something in xHE-AAC (USAC) here's a link to the video I encoded:

https://odysee.com/@InfinityHD:0/mf_avqlab:c

The original audio was a lossless 24-bit/48kHz DTS-HD MA track, which was encoded into xHE-AAC at 192 kbit/s using the command I mentioned in my previous post.

The video is a 2560x1440 10-bit AV1 stream (~4700kbit/s avg). It was restored from an extremely grainy Blu-Ray source using Stable Diffusion.

Re: exhale - Open Source USAC encoder

Reply #1222 –
Quote from: Leo 69 on
To anyone wanting to listen something in xHE-AAC (USAC) here's a link to the video I encoded:

https://odysee.com/@InfinityHD:0/mf_avqlab:c

The original audio was a lossless 24-bit/48kHz DTS-HD MA track, which was encoded into xHE-AAC at 192 kbit/s using the command I mentioned in my previous post.

The video is a 2560x1440 10-bit AV1 stream (~4700kbit/s avg). It was restored from an extremely grainy Blu-Ray source using Stable Diffusion.

Okay, it's actually xHE-AAC. I can't watch it in chrome or another browser (since I don't have xHE-AAC support, except in foobar2000 and PotPlayer). After download it I can hear the audio. But in my opinion there's almost no point to use xHE-AAC at these bitrates, Opus is good enough and has much more support.
Ah, and AV1 decoding uses ~50% of cpu (in the VM for the tests, I wouldn't try anything in the main system).
Audio coding scene seems to be more relaxed than video one, in video there are a lot of significant projects, and everybody is still searching how to reduce files (not exactly increase quality), and then efficience is droping down. I know that video coding is more complex than audio, but actually is too slow. H266 and AV1 ::)...