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 304438 times) previous topic - next topic
0 Members and 3 Guests are viewing this topic.

Re: exhale - Open Source USAC encoder

Reply #775
what is the right link for the develop branch? can anyone view it or only the one logged in gitlab?

Re: exhale - Open Source USAC encoder

Reply #776
I think that this is a good choice. As you discovered recently, SBR mode gives slightly better quality on low bitrate so choosing standard mode 2 vs mode d should be fair choice. Mode 2 will gain slight advantage in bitrate to compesate for slightly lower quality compared against sbr mode d. If mode d could keep up with 5-7 kbps lower bitrate to match, or even surpass mode 2 quality, than you get both quality and efficiency at slightly lower bitrate.
Should be interesting to see the results. :)
I've started the comparison between 2 and d. Thanks your your advice!


Re: exhale - Open Source USAC encoder

Reply #778
Windows Insiders build 21370

Quote
Support for AAC codec: Enjoy premium audio streaming quality wirelessly on your Bluetooth headphones and speakers with AAC codec. Short for Advanced Audio Codec, AAC is a lossy codec that delivers high quality audio streaming in smaller files – great for listening to music online.
https://blogs.windows.com/windows-insider/2021/04/29/announcing-windows-10-insider-preview-build-21370/

Including Extended High Efficiency AAC xHE-AAC – defined in 2012, uses USAC

Re: exhale - Open Source USAC encoder

Reply #779
Great news, thanks for letting us know! Was anyone able to test xHE-AAC playback on that insider build?

I just finished the stable exhale 1.1.5 release (9a1c4ee3) which, on top of the RC, improves encoding of the very last frame when using the command-line exhale.exe directly (not through e.g. foobar2000).

Changes since exhale 1.1.4 from last month:
  • exhaleApp: correct print-out of Unicode file names and paths, minor code cleanup
  • exhaleLib: minor tuning of immediate playout frames, no changes to audio quality
  • makefile: support for compilation of Universal 2 binaries on MacOS™ (C. Snowhill)

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

Re: exhale - Open Source USAC encoder

Reply #780
Intel compiles of exhale-V1.1.5-9a1c4ee3 now at Rarewares.



Re: exhale - Open Source USAC encoder

Reply #783
exhale v1.1.5-9a1c4ee3
foobar

USAC/SBR
Error on some tracks and they're unplayable.

No errors on USAC regular mode.

Used John and NetRanger downloads and produced the same errors.

Re: exhale - Open Source USAC encoder

Reply #784
Please try again with the latest component. I fixed a regression, and updated the SDK. If it persists, please PM me a non-working file to look at.

Re: exhale - Open Source USAC encoder

Reply #785
Please try again with the latest component. I fixed a regression, and updated the SDK. If it persists, please PM me a non-working file to look at.
Still having the same errors on SBR.

Re: exhale - Open Source USAC encoder

Reply #786
PM me a file that's failing, then. I suggest 0x0.st as an upload target, if you have a copy of CURL to interface with it. It's like ix.io, but also accepts binary files of most types. (Except for executables.)

Re: exhale - Open Source USAC encoder

Reply #787
Your broken file is not a valid MP4 file. In fact, it isn't a valid anything file. It appears to be random garbage.

Re: exhale - Open Source USAC encoder

Reply #788
C.R.Helmrich found the problem with SBR.


Re: exhale - Open Source USAC encoder

Reply #789
Yes, it's the same issue guruboolez and others once reported, some unreliable behavior on some Windows systems when using exhale via stdin (e.g. in foobar2000) and in parallel.

I guess I'll have to take another look at exhale's PCM reading routine in case of standard input. For now, the message linked to above describes how to configure the code to run more reliably (but slower).

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


Re: exhale - Open Source USAC encoder

Reply #791
There may be something wrong with my SBR decoding? I need to recheck my library code.

Edit: An important fix to a regression introduced at some point: 1.21 fixes the decoder configuration not being applied to the separate decoder used for first packet analysis, which was causing the output delay to be overwritten, causing the default configuration of no PCM limiter to result in 5ms, the default limiter attack time, being chopped off of the output when the limiter is disabled. This is now fixed.

I am attempting to pass the xHE-AAC compliance tests as well, but there's a strange issue with the SBR output not being identical to a reference output. There's as much as a 0.033 peak difference between the two, and a spectral analysis of the difference shows that the spectra is entirely restricted to the SBR output.

Re: exhale - Open Source USAC encoder

Reply #792
Can the quality level be adjusted?


Re: exhale - Open Source USAC encoder

Reply #794
Dear @john33, I see one weird char on the news page of Rarewares.
• 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 #795
When using libfdk decoder with ffmpeg for xHE-AAC files, DRC is enabled by default. Does this mean that it is enabled in fdk on Android too?

Re: exhale - Open Source USAC encoder

Reply #796
@kode54 , in AAC Packet Decoder option description for DRC reference level says that disabled is -1. But description of options for libfdk in ffmpeg says that disabled is -2 and auto is -1.
Code: [Select]
-drc_level         <int>        .D..A...... Dynamic Range Control: reference level, quantized to 0.25dB steps where [0] is 0dB and [127] is -31.75dB, -1 for auto, and -2 for disabled (from -2 to 127) (default -1)
Is description in AAC Packet Decoder correct?

Re: exhale - Open Source USAC encoder

Reply #797
Does it mean that previously all xHE-AAC files were decoded in 16 bits even if 24 bits decoding was enabled in foobar2000?
Yes, I just checked again with an older version of kode54's FDK-AAC packet decoder - only the upper 16 bits were actually used even when converting to 24 bits. I recommend updating to the new version 1.21 of the packet decoder.

enc v1.1.5-9a1c4ee3, dec v1.19
#a-e - poor sound quality at the output (foobar).
Thanks for reporting! I forgot to re-tune some constant for the SBR modes. Will be fixed in the next exhale release. Attached a preview for this particular item (preset d, mod is the new version).

The "Medium"? Is that assigned by dBpoweramp then?
I guess so, exhale certainly doesn't write a "Medium" quality indicator into the xHE-AAC files. The "medium" description does seem to make sense at this bit-rate, though, so not an issue IMHO.

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

Re: exhale - Open Source USAC encoder

Reply #798
Yes, it's the same issue guruboolez and others once reported, some unreliable behavior on some Windows systems when using exhale via stdin (e.g. in foobar2000) and in parallel.

Chris

I faced conversion foobar2000 issue several times but considered as Jupiter is not in the right triangle if u understand my humor. BTW looks like real bug somewhere in code.

Re: exhale - Open Source USAC encoder

Reply #799
I can't even guarantee my plugin is outputting the correct bit depth for SBR. FDK-AAC seems to be totally broken if you don't output the default 16 bits rounded.