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

Re: exhale - Open Source USAC encoder

Reply #1000
EZ CD Audio Converter 9.5.2 with Exhale v1.1.8.1 released. Also includes Fraunhofer IIS xHE-AAC update with more sample rates in low bitrate encoding.

Re: exhale - Open Source USAC encoder

Reply #1001
Thanks Jurgga, I appreciate the continued improvements in speech compression and xHE-AAC in VBR Q1 (36kbps, which becomes less than 24kbps if there is only speech) 48kHz mono is my preferred choice although I am beginning to fear that I will not use never USAC in my work. If the idea of ​​being able to use only one format for speech on each medium excites me, the absence of a decoder pre-installed even in Windows 10 keeps me from innovating in the same way as the impossibility of reproducing Opus (which has a best support) on iPhones that do not yet reproduce this format when embedded in Webm.

The war of containers after that of formats has tired me. Despite your work today I don't see only better speech than AAC LC, despite the bitrate (since I don't like to hear HE-AAC and in this I am in tune with many in my country).

Hoping not to have to wait for another 1,000 answers (yours was just the number 1,000) to see such a simple problem solved. The users of this forum do not represent the generality of the population and when the choice does not concern personal use, in my opinion, any changes must be postponed.

Re: exhale - Open Source USAC encoder

Reply #1002
I think I wrote 2 incomprehensible sentences. My frustration is for operating systems unable to add what is commonly found elsewhere, for example the ability to reproduce standardized formats, like Microsoft years after their own press releases, or when contained in known structures, always Microsoft which for example does not make Opus usable when incorporated in ISO, or Apple, which deserves to be laughed at for the number of years it takes for Ogg and Webm. In summary if one wanted to use the HTML <audio> tag without JS as of today, they still have to provide the same content in multiple formats.

None of those who produce content in this way will change format, making life difficult for those who produce coding software. This is my thought.

Re: exhale - Open Source USAC encoder

Reply #1003
FWIW, in spite of announcements that it should work, I can't even make Windows 11 (Pro version, clean install) and its apps (e.g. Groove Music) recognize USAC .m4a files. "This item is in a format we don't support. 0xc00d36b4"

 

Re: exhale - Open Source USAC encoder

Reply #1004
FWIW, in spite of announcements that it should work, I can't even make Windows 11 (Pro version, clean install) and its apps (e.g. Groove Music) recognize USAC .m4a files. "This item is in a format we don't support. 0xc00d36b4"

Has anyone tried the *new* Media Player App for Windows 11 with xHE-AAC ?

Re: exhale - Open Source USAC encoder

Reply #1005
Out of curiosity, which exhale binary build for windows is more optimised/fast, john33's Rarewares or NetRanger's?
Usually rareware's executable size for x64 is half of NetRanger's.

Re: exhale - Open Source USAC encoder

Reply #1006
This is because NetRanger works for the KGB and sets a "Honey Trap" in the binary.

Re: exhale - Open Source USAC encoder

Reply #1007
At least not for Facebook Ouch my bad: As per TOS8 I shall not claim that Facebook is different from a malicious dictatorship, as long as I have no evidence but the sighted evaluation of the glossy appearance.

Re: exhale - Open Source USAC encoder

Reply #1008
I habe being testing exhale encoder, it's a great piece of software, thank you, It also sounds excellent, even at the lowest bitrates, it outperforms the reference fdk standard he-aac encoder at 48 kbps in some speech that I have encoded, the file ended with fdk aac encoder presents the typical SBR high pitched annoying artifacts, while the file encoded with exhale and eSBR is free from annoying artifacts.
I would like to know: What ids the ifference between the standard SBR and the enhanced spectral band replication improvement? What are the other new tools supported in exhale, which are not present in a standard aac encoder?

Re: exhale - Open Source USAC encoder

Reply #1009
Sorry, I have realized that I have mistyped a couple of words, please accept my apologize for the inconvenience, this is the correct text I intended to post:
Hi, I have being testing exhale encoder, it's a great piece of software, thank you, It also sounds excellent, even at the lowest bitrates, it outperforms the reference fdk standard he-aac encoder at 48 kbps in some speech that I have encoded, the file encoded with fdk aac encoder presents the typical SBR high pitched annoying artifacts, while the file encoded with exhale and eSBR is free from annoying artifacts.
I would like to know: What is the difference between the standard SBR and the enhanced spectral band replication upgrade technically? What are the other new tools supported in exhale, which are not present in a standard aac encoder?

I hope I fixed all errors in my text message.

Re: exhale - Open Source USAC encoder

Reply #1010
You can find a comprehensive description of the new coding tools in the xHE-AAC (or USAC) standard in this journal article:
https://www.gel.usherbrooke.ca/gournay/documents/publications/JAES_V61_12_PG956.pdf
eSBR, for example, is described in Section 3.3, but note that exhale doesn't implement the improvements described in subsections 3.3.2-3.3.5. The main cause of the improvements you hear is probably that exhale lets the SBR coding start at a higher frequency than some other HE-AAC encoders.

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


Re: exhale - Open Source USAC encoder

Reply #1012
Thank you for your reply, I am eager to read the article.

Re: exhale - Open Source USAC encoder

Reply #1013
Regarding
Has anyone tried the *new* Media Player App for Windows 11 with xHE-AAC ?
Media Player preview will not play anything because of errors.

I also see these posts from October:
Yes astonishing it does, I can play a USAC .m4a file in Groove music player... Windows 11 default music player
I can confirm USAC in windows 11 media player.
Dev channel.

I'm confused. Didn't you and griploner write in the above messages that it works? Are we talking about different versions of the Windows 11 Media Player? Which one is the default version on a fresh Windows 11 (not Developer preview) installation?

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

Re: exhale - Open Source USAC encoder

Reply #1014
Classic Windows Media Player works just fine, but Media Player preview is full of errors.


Re: exhale - Open Source USAC encoder

Reply #1015
USAC probably does not work -yet- in Windows 11 Pro (the current vanilla release 21H2 22000.348; not dev builds or other esoteric stuff).
No matter the player used: neither Windows Media Player (WMP, the old-style player inherited from the last century) nor Groove Music (the default music app and player for .m4a) can decode the audio, with only one error message (hence not "full of errors").

Re: exhale - Open Source USAC encoder

Reply #1016
Both players install on Dev build (Win11) and run separately.

I've played around with the preview version and got the permissions set correctly now, so it will play m4a at 40 kbps.



Re: exhale - Open Source USAC encoder

Reply #1019
The Dev channel
Build 22518.1012

https://blogs.windows.com/windows-insider/2021/11/16/new-media-player-for-windows-11-begins-rolling-out-to-windows-insiders/

Thanks. It might take months till such new beta/dev features land in the mainstream releases (if they ever do properly! see e.g. Opus metadata in Groove Music)...
USAC/xHE-AAC remain unsupported on Windows 11 for the time being. :(

Re: exhale - Open Source USAC encoder

Reply #1020
I've just upgraded from Mac OS Big Sur directly to Monterey v12.1 on Apple M1 Air and foobar2000 (M1 native version) can no longer play USAC M4A files. The error message says "Playback error: unsupported format or corrupted file".

Has anyone else experienced this?

Re: exhale - Open Source USAC encoder

Reply #1021
This appears to be a bug in how the system codecs are invoked to support that format. This bug does not appear to affect Cog, which also doesn't implement support in the same way.

Re: exhale - Open Source USAC encoder

Reply #1022
I bumped exhale's version number one last time and finished a 1.1.9 release candidate. The only difference to the intermediate 1.1.8.1 from early November is that the exhale command-line application now writes a encoder name and version string as a "tool" tag into the MPEG-4 header, so programs like foobar2000 can display "exhale 1.1.9" in their File properties dialogs.

Please report any problems you might have with this additional metadata tag. I'll make a final 1.1.9 release tag at the end of the year.

Changes since version 1.1.8 from October 2021:
  • exhaleApp: write encoder name and version as «udta» tool string into MP4 header
  • exhaleApp: optimize leading and trailing PCM read for gapless playback (issue 21)

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

Re: exhale - Open Source USAC encoder

Reply #1023
I'm currrently away from home until after 7 January. I have created compiles which I will attempt to upload to Rarewares later today. :)

Re: exhale - Open Source USAC encoder

Reply #1024
I attempted to port libvorbis's linear predictor into the gapless extrapolator, and it appears to have zero difference from what's currently in place. I'll stash the changes anyway, in case anyone finds them useful.

https://gist.github.com/kode54/20f035dee343f5668796cad46be78d8b

(Original code modified to use in-place variable length arrays instead of alloca())

Binaries for macOS Universal Intel+ARM: