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

Re: exhale - Open Source USAC encoder

Reply #801
Another release. I still can't figure out why 32 bit builds of FDK-AAC are broken and produce bad SBR output.

Edit: Okay, it appears Peter's bitstream parser is handing me bad data.

Re: exhale - Open Source USAC encoder

Reply #802
I see it now showing PS presence. Nice :)
--------------------

Re: exhale - Open Source USAC encoder

Reply #803
Same problem with accb67be

foobar2000 1.6.6 beta 6
fdk-aac pack decoder 1.22
Windows 10 build 21370

Re: exhale - Open Source USAC encoder

Reply #804
Are you sure you're even encoding files properly? I literally have no idea how your machine is managing to make the encoders interfere with each other when they're separate processes. Literally, the files you shared with me were just random garbage, not even valid MP4 files.

@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?
Well, the headers in the library say the valid range of options is 40...127, 96 (-24 dB) is the default, and -1 is disabled.

Also, I found the decode error that was causing me to fail validation for some files. It seems foobar is dropping the first packet for those files, so I'm not even decoding it.

 

Re: exhale - Open Source USAC encoder

Reply #805
I faced conversion foobar2000 issue several times but considered as Jupiter is not in the right triangle if u understand my humor.
Same problem with accb67be
I haven't fixed that issue yet, you'll have to rely on the last executable that worked for you. Like I mentioned before (I think), I do not observe this issue on my own PC when e.g. converting my FLACs to xHE-AAC, which makes it hard to debug. It really seems to depend on the hardware/driver/software configuration.

But can you two check if things get any better if you disable the metadata transfer during conversion? See this old Wiki entry for instructions.

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

Re: exhale - Open Source USAC encoder

Reply #806
How is this even an issue? The executables shouldn't be interacting with each other.

Re: exhale - Open Source USAC encoder

Reply #807
I have an AMD Ryzen 9 3900X 12-core
32 GB ram at 3200 MHz
ASUS ROG Strix B450-F
970 EVO Plus SSD 1TB - M.2 NVMe
That's the hardware I'm working with.

The encoder set 108kbps / Preset g
Processing: None.
Other: When finished:
* Transfer tags and attached pictures.

Flac and Opus files no problem.

Re: exhale - Open Source USAC encoder

Reply #808
Can you please try again with the latest commit to exhale's Git repository? That version tries to stabilize the WAVE reading routine for some users and also includes a very minor fix for SBR encoding of very low-level signals.

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


Re: exhale - Open Source USAC encoder

Reply #810
Success!

John's compile.
exhale-V1.1.5-aaf8b0aa works %100.


Re: exhale - Open Source USAC encoder

Reply #812
I need some help. I am using exhale in foobar for converting WAV & FLAC into m4a but my converted files dont have any sound and it shows as corrupted file or unsupported format in foobar(i am using latest version of foobar & exhale). Can anyone please help me with guide of using exhale in foobar or any other method which is easy to follow? I followed official guidelines but they are unable to help me.




Re: exhale - Open Source USAC encoder

Reply #816
enc v1.1.5-aaf8b0aa, dec v1.22
#2-9 -  in the area of 6.6 khz, the sound balance is damaged. (foobar, win64).

Re: exhale - Open Source USAC encoder

Reply #817
Please everyone update the decoder again. There were some issues I was able to fix, regarding IPF dependency, and some compliance behavior with some SBR output due to briefly changing some defines in libFDK-AAC.

Re: exhale - Open Source USAC encoder

Reply #818
Please everyone update the decoder again. There were some issues I was able to fix, regarding IPF dependency, and some compliance behavior with some SBR output due to briefly changing some defines in libFDK-AAC.
Thanks kode54 for your continued efforts/expertise on this needed plugin.


Re: exhale - Open Source USAC encoder

Reply #820
Thanks, but can you briefly explain what you think is wrong on that sample, as in your previous posts? That would save me some time.

Regarding the chirp: that's actually a safety net kicking in, which only happens on noise-free test tone signals like sine sweeps. I converted your 24-bit FLAC to 16 bits/sample with a bit of dither, and the drop-out seems to disappear. So nothing to worry about.

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

Re: exhale - Open Source USAC encoder

Reply #821
Lines_chord_loop_Gmin - fdk-aac tries to isolate the unpleasant quantization noise at the output at high frequencies (merit of he-v2). xHE allows dirt to pass through.
Chirp - 24bit to 16bit + dithering helped! Can you recommend all 24bits on an automatic basis to be subjected to this procedure?


Re: exhale - Open Source USAC encoder

Reply #822
No, you don't need to down-convert your 24-bit music to 16-bit before encoding with exhale. As I said, this only affects test signals. Specifically, it affects recordings of isolated loud tones where the lower-frequency neighboring spectrum is at least ~90 dB quieter. That usually doesn't happen in natural audio, only in synthetic test signals.

Regarding Lines_chord_loop, that's a design choice I made (to improve coding of transients), not a bug. But I noticed that your sample, which is a mono-in-stereo signal, uses a bit-rate much lower than the target rate, and this kind of undercoding also happens with the higher-rate SBR presets and, in that magnitude, was unintended. So I improved exhale's behavior on such corner-case audio files. Regular stereo music should not be affected, so no need to re-encode anyone's collection.

Thanks again for reporting!

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


Re: exhale - Open Source USAC encoder

Reply #824
When will foobar learn to display version-build number in file details?