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

Re: exhale - Open Source USAC encoder

Reply #350 –
Chris, I've just created a patch to write stss.

Without stss, seek on ffmpeg based player behaved pretty badly (I've tried ffplay and mpv, built with --enable-libfdk-aac).
This is some expected result.

With stts, it was good. I mean, ffmpeg already knows how to handle stss, and things work without any modification on ffmpeg side.
I believe this is the way to go.

Re: exhale - Open Source USAC encoder

Reply #351 –
Thanks very much! OK, you convinced me, I was hoping I could avoid those extra bytes in the MPEG-4 header, but it seems I can't. I had already started writing my own fix, which is slightly more compact in terms of code changes (no need for changes in the header file). Please check out commit 051900fe and let me know if this fixes the playback issue with ffmpeg/FDK based decoders as well. The old behavior, which has been fixed to identify at least the very first AU in each file as being an IF, can be reactivated by defining NO_FIX_FOR_ISSUE_13 in the exhale application.

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

Re: exhale - Open Source USAC encoder

Reply #352 –
Intel compiles of exhale-v.1.0.7-051900fe:

www.rarewares.org/files/aac/exhale-v.1.0.7-051900fe_x64.zip

www.rarewares.org/files/aac/exhale-v.1.0.7-051900fe_x86.zip

I have elected to name these as 1.0.7 but I'm sure I'll be told if that is incorrect!! ;)

Re: exhale - Open Source USAC encoder

Reply #354 –
Quote from: C.R.Helmrich on
Please check out commit 051900fe and let me know if this fixes the playback issue with ffmpeg/FDK based decoders as well.
051900fe is OK. seek is working on ffmpeg+FDK-AAC combo.

Re: exhale - Open Source USAC encoder

Reply #355 –
Wanna try this but I'm confused on what the Foobar encoder settings are?.
Got locked out on a password i didn't remember. :/
 

Re: exhale - Open Source USAC encoder

Reply #357 –
Quote from: ani_Jackal3 on
Wanna try this but I'm confused on what the Foobar encoder settings are?.

Something like this.

Also, for reference:

CBR mode 1 = ~64 kbps (stereo)
CBR mode 2 = ~80 kbps (stereo)
CBR mode 3 = ~96 kbps (stereo)
CBR mode 4 = ~112 kbps (stereo)
CBR mode 5 = ~128 kbps (stereo)
CBR mode 6 = ~144 kbps (stereo)
CBR mode 7 = ~160 kbps (stereo)
CBR mode 8 = ~176 kbps (stereo)
CBR mode 9 = ~192 kbps (stereo)

Re: exhale - Open Source USAC encoder

Reply #359 –
Thanks.
Got locked out on a password i didn't remember. :/

Re: exhale - Open Source USAC encoder

Reply #360 –
Quote from: C.R.Helmrich on
exhale version 1.0.6 ...

Changes since exhale 1.0.5 from last month:
- bugfixes, improved quality on some transient signals, better decoder compatibility
- exhaleApp: support for Extensible WAVE format, write MP4 «prol» data (issue #10)
- exhaleApp: automatic downsampling of 48-kHz input to 32 kHz for CVBR mode 1
- exhaleLib: fine-tuning of psychoacoustic model for difficult transient input signals

I thought it was important to mention that starting from 1.0.6. release for the first time exhale outperforms every LC-AAC encoder at 80-96 kbps (and higher).

Also despite exhale having CVBR bitrate control now 1.0.6 performs on par with Opus with unconstrained VBR at those rates. Means that now You get a same quality and more predictable bitrate/filesize with exhale.

Great work.

Quote from: john33 on
Intel compiles of exhale-v.1.0.7-051900fe:

www.rarewares.org/files/aac/exhale-v.1.0.7-051900fe_x64.zip

www.rarewares.org/files/aac/exhale-v.1.0.7-051900fe_x86.zip

I have elected to name these as 1.0.7 but I'm sure I'll be told if that is incorrect!! ;)
I think 1.0.7 is correct as it's a first alpha after the last 1.0.6 stable release.
BTW thank you for builds.

Re: exhale - Open Source USAC encoder

Reply #361 –
Are there any other xHE-AAC encoders to compare with? I've heard of the StreamS Live Encoder which appears to be the industry-standard according to Wikipedia, but it isn't marketed to or priced for home users.

Re: exhale - Open Source USAC encoder

Reply #362 –
And Apple claims to support xHE-AAC in their systems, starting with Catalina, and recommend programming to involve it in your workflow. But... they don't provide an encoder. Only a decoder.

Re: exhale - Open Source USAC encoder

Reply #363 –
Greetings from the lurking darkness,

Signed up just to post this question, any help by the esteemed experts here would be awesome!

Are we able to use exhale for streaming to stdout? Like with a shoutcast/icecast server being driven by Breakaway's encoding section via custom encoders? It's possible to do so with the other aac+ command line encoders (ie: qaac, fdkaacenc, fhgaacenc, and even the older enc_aacplus) , i just couldn't find any switches to indicate stdout for the output (ie: '-').

Much thanks for the great codec work goes to Mr. Helmrich!  :-D

-Y

 

Re: exhale - Open Source USAC encoder

Reply #364 –
Hi all,

For some time I was looking for an xhe encoder in order to try very low bitrate for some audio books (tried 16kbps he-aacv2 but this results in metallic voice). Any chance in supporting such bitrates?
Also for some stereo music I'm curious if xhe can keep some quality below 24kpbs, like he-aacv2 does in 24k.

Re: exhale - Open Source USAC encoder

Reply #365 –
Quote from: rogeriol on
Hi all,

For some time I was looking for an xhe encoder in order to try very low bitrate for some audio books (tried 16kbps he-aacv2 but this results in metallic voice). Any chance in supporting such bitrates?
Also for some stereo music I'm curious if xhe can keep some quality below 24kpbs, like he-aacv2 does in 24k.
Not at the moment:
Quote
Its objective is high quality mono, stereo, and multichannel coding at medium and high bit rates, so the lower-rate USAC coding tools (ACELP, TCX, Enhanced SBR and MPEG Surround with Unified Stereo coding) won't be integrated.
If those features are implemented then technically xHE-AAC should sound better than HE-AACv2 at 24kbps. For now your best bet will be HE-AACv2 for music and also trying Opus for voice only at those bitrates.

Re: exhale - Open Source USAC encoder

Reply #366 –
Quote from: yarrix on
Are we able to use exhale for streaming to stdout? Like with a shoutcast/icecast server being driven by Breakaway's encoding section via custom encoders? It's possible to do so with the other aac+ command line encoders (ie: qaac, fdkaacenc, fhgaacenc, and even the older enc_aacplus) , i just couldn't find any switches to indicate stdout for the output (ie: '-').
This is currently not supported by the exhale application because, after finishing an encoding, it goes back to the beginning of the file to write the final MPEG-4 file header. It's written to the beginning of the file to optimize the resulting .m4a files for streaming (fast start of playback and seeking). AFAIK this approach is not possible with stdout. However, one could use the exhale library to build a custom solution doing exactly what you're looking for.

Quote from: rogeriol on
For some time I was looking for an xhe encoder in order to try very low bitrate for some audio books (tried 16kbps he-aacv2 but this results in metallic voice). Any chance in supporting such bitrates?
Also for some stereo music I'm curious if xhe can keep some quality below 24kpbs, like he-aacv2 does in 24k.
Regarding support for bit-rates lower than, say, 48 kbit/s stereo (or 24 kbit/s mono), I commented on this in an earlier post. Summary: sorry, too much work for me, I do this in my free time.
Regarding the 24 kbit/s stereo music quality, the xHE-AAC standard does very well there, see the USAC verification test report from 2011. Figure 2 of that report is attached.

Quote from: IgorC on
I thought it was important to mention that starting from 1.0.6 release for the first time exhale outperforms every LC-AAC encoder at 80-96 kbps (and higher).
Awesome, that's great to hear! Thanks very much for testing, Igor!

Quote from: john33 on
I have elected to name these as 1.0.7 but I'm sure I'll be told if that is incorrect
That's OK, but to avoid confusion in the future, please always use the version number written in include/version.h in exhale's source directory.

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

Re: exhale - Open Source USAC encoder

Reply #367 –
Quote from: C.R.Helmrich on
Quote from: yarrix on
Are we able to use exhale for streaming to stdout? Like with a shoutcast/icecast server being driven by Breakaway's encoding section via custom encoders? It's possible to do so with the other aac+ command line encoders (ie: qaac, fdkaacenc, fhgaacenc, and even the older enc_aacplus) , i just couldn't find any switches to indicate stdout for the output (ie: '-').
This is currently not supported by the exhale application because, after finishing an encoding, it goes back to the beginning of the file to write the final MPEG-4 file header. It's written to the beginning of the file to optimize the resulting .m4a files for streaming (fast start of playback and seeking). AFAIK this approach is not possible with stdout. However, one could use the exhale library to build a custom solution doing exactly what you're looking for.

Chris

Thanks for the detailed info Chris, your suggestion is beyond me personally, but I'm sure that a lot of streamers would be extremely interested in such a 'library' version for streaming. Maybe some of the folks who kindly 'compile' your source could take a shot at it? Or maybe even you could decide to do this, as the use case is way more than obvious. Hint hint! ;-D

Nevertheless, with my limited knowledge of these things, I see two main hurdles; first is raw/pcm on stdin input (not just orderly wav), and adts on output to stdout (not m4a output). Am I on the right track? Thanks again for any pointers, highly appreciated!
 

-Y

Re: exhale - Open Source USAC encoder

Reply #368 –
Quote from: yarrix on
Nevertheless, with my limited knowledge of these things, I see two main hurdles; first is raw/pcm on stdin input (not just orderly wav), and adts on output to stdout (not m4a output). Am I on the right track?
I don't know, you tell me. Is that how the workflow with Shoutcast/Icecast is? Does it require ADTS output from the encoder?

By the way, I just committed some minor fixes to the exhale source code (mostly affecting 32-kHz encoding especially at CVBR modes 4 and higher, which is what most people probably don't do), so we have a 1.0.7 beta now.

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

Re: exhale - Open Source USAC encoder

Reply #369 –
According to the following doc, ADTS is deprecated.
LATM/LOAS shall be used instead.
MPEG-TS or fragmented MP4 can also be used for streaming purpose.
https://www.iis.fraunhofer.de/content/dam/iis/de/doc/ame/wp/FraunhoferIIS_xHE-AAC_Whitepaper.pdf
Quote
LATM/LOAS
When xHE-AAC is stored or transmitted “raw”, i.e. without an additional container, multiplexing and streaming is enabled by the MPEG-4 Low Overhead Audio Transport Multiplex (LATM) and the Low Overhead Audio Stream (LOAS) [MP4A]. Support for the alternative Audio Data Transport Stream (ADTS), which was common for AAC-LC and HE-AAC,
is deprecated with xHE-AAC and not supported anymore. LATM/LOAS is typically used in
SHOUTcast deployments.
Also, the following was  interesting:
Quote
File-format (ISOBMFF/MP4FF)
Storage of xHE-AAC in the ISO base media file format (ISOBMFF)[ISOBMFF] follows the
same principles as AAC-LC and HE-AAC, i.e. the MP4 file format [MP4FF] is used.
All IPFs are signaled by means of the “SyncSampleBox”. IPFs allow the decoder to fully
reconstruct the signal without any previous AUs, which enables true random access at any
sync sample. This is particularly useful when a flat MP4 file is used as input to a streaming
system for subsequent fragmentation. Signaling of IPF is mandatory for xHE-AAC.
Since the xHE-AAC encoder works on a fixed “granule” of e.g. 2048 audio samples, the
last AU of an MP4 file usually represents only the last few samples of the original WAV
file. In order to restore this original file length, an edit-list can be used to trim the MP4 file
accordingly. It is recommended that an xHE-AAC file starts with an IPF, which addresses
the “priming” issue (see above) and removes the need for edit lists at the start of the
item.
In addition to the rather expensive IPFs, all AUs that have the usacIndependencyFlag set
to 1 can be used to enable random access, e.g. for seeking operations. While these Independency Frames (IF) can be used to start decoding, a full audio signal is guaranteed only
after decoding a certain number of AUs. This is referred to as roll distance in file format
terms and can be signaled using the AudioPreRollEntry and the AudioSampleGroupEntry
respectively.
So, if exhale is generating IPF(immediate playout frame)s, using stss is the right thing to do.
Otherwise, the doc doesn't clearly say if stts is mandatory or not.

If I understand correctly, you still need to seek to one of independency frame(IF)s from where you can start decoding. So, I believe you still need stss.
If they are not IPFs, decoder can start from there, but IFs are dependent to the preceding frames (due to by nature of MDCT).
So, if you want full/accurate reconstruction from the exact seek point, you have to also take prerolling into account.
AudioPreRollEntry can be used to let player know how many preroll they need, and this is what doc says.

Re: exhale - Open Source USAC encoder

Reply #371 –
Quote from: nu774 on
So, if exhale is generating IPF(immediate playout frame)s, using stss is the right thing to do.
Otherwise, the doc doesn't clearly say if stts is mandatory or not.
...
AudioPreRollEntry can be used to let player know how many preroll they need, and this is what doc says.
Exactly. I agree that the 'stss' box should be used and, according to my understanding, the AudioPreRollEntry ('prol' of one sample, i.e., one AU, 1024 audio samples) was added in the context of issue 10. Please let me know if that is unrelated or incorrect.

By the way, just had to fix a Linux compilation error, so there's a new commit (thanks, m14u!). John, no need to update, doesn't affect Windows.

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

Re: exhale - Open Source USAC encoder

Reply #372 –
aa44938c
caramba!

Re: exhale - Open Source USAC encoder

Reply #374 –
Thanks, NR   ;D
EZ CD Audio Converter / FLAC or WavPack