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


Re: exhale - Open Source USAC encoder

Reply #702
exhale v1.1.4-27e9e9e0 {Stable} {macOS} {Universal}
Built on March 29, 2021, clang 12.0.0 (clang-1200.0.32.29)

Re: exhale - Open Source USAC encoder

Reply #703
By C/C++ standard, mixing char/wchar_t output to a same stdio file / iostream is not guaranteed to work.
... you have to stick to wchar_t oriented printing functions everywhere.
nu774, you saved the day (once again). :) The combination of your and Case's suggestion (for stderr instead of stdout in my case) does the trick. So thanks again to both of you. Now I just need to figure out how to shorten all these printfs... With all the #ifdef ...WCHAR, #else duplications, the code in exhaleApp.cpp has gotten nearly unreadable. Spaghetti code, indeed.

Basically, you need all the compile and link command lines to have -arch arguments for every arch you're building or linking. I patched the Makefiles to accept a config switch to turn that on:
Code: [Select]
make UNIVERSAL2=1
Is that something I should be committing to my main Git branch? Sounds like it could save people some time when updating their Mac binaries after a new exhale release.

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

Re: exhale - Open Source USAC encoder

Reply #704
Probably totally safe to do, for now. It can build with that option on Xcode 12.2 or later, or the command line tools for 12.2 or later. Otherwise, it will default to building whatever the current machine's architecture is, and it will default the target version to the maximum supported by the currently installed SDK.

Re: exhale - Open Source USAC encoder

Reply #705
C.R.Helmrich
Unicode bug mutated a bit, but is still there. For example, question marks are gone, but no actual symbols are displayed.

celona
Decifra questo codice e goditi il capolavoro :D aHR0cHM6Ly9vc2hpLmF0L3hzUGdlRSANCg==
• 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 #706
Very clever link obfuscation, my dude. I approve.

Edit: Please try running it under Windows Terminal. No, I am not joking, this is literally what the app is called. You may find it either in the Microsoft Store, or on Microsoft's Github project page for it. CHCP isn't needed to run Unicode apps under the terminal, it only changes what 8 bit encoding is used for ANSI API. And incidentally, Windows 10 20H1 is the first version of Windows to support UTF-8 for that, and not just consider it a hack.

Re: exhale - Open Source USAC encoder

Reply #707
celona
Decifra questo codice e goditi il capolavoro :D aHR0cHM6Ly9vc2hpLmF0L3hzUGdlRSANCg==

Why me? I chose not to hurt myself, I have been using UTF-8 since 1999 when I discovered an operating system called BeOS R4.5.

Re: exhale - Open Source USAC encoder

Reply #708
It's a base64 encoded short URL that leads to a lovely download, but I'm not sure our forum can allow it to stay forever.

Re: exhale - Open Source USAC encoder

Reply #709
It would be of great interest to me (and maybe others?) if you could add one high bitrate test at 192 kbs for both codecs for a vocals-with-music source to check how the "9" encoding level of Exhale performs against Opus.
Unfortunately, testing modern codecs at 192kbps is very costly since they will be very close to the original. It won't fit in my two-month budget. IgorC already tested on xHE-AAC 1.0.7.0 -m 9 (~192 kbps) vs Opus 1.3.1 -b 182, with 12 music samples, and Opus was rated 5.0 for all the 12 samples, while xHE-AAC was transparent on only 7 samples.
https://hydrogenaud.io/index.php?topic=120007

Re: exhale - Open Source USAC encoder

Reply #710
C.R.Helmrich
Unicode bug mutated a bit, but is still there. For example, question marks are gone, ...
Patience, please. I haven't changed anything publicly yet, busy with other stuff this week.

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

Re: exhale - Open Source USAC encoder

Reply #711
Unfortunately, testing modern codecs at 192kbps is very costly since they will be very close to the original. It won't fit in my two-month budget. IgorC already tested on xHE-AAC 1.0.7.0 -m 9 (~192 kbps) vs Opus 1.3.1 -b 182, with 12 music samples, and Opus was rated 5.0 for all the 12 samples, while xHE-AAC was transparent on only 7 samples.
https://hydrogenaud.io/index.php?topic=120007
Thanks Kamedo2 for the reply and for pointing me to IgorC's test which somehow I missed, much appreciated!

Re: exhale - Open Source USAC encoder

Reply #712
OK, so all my attempts to save some code lines by putting all printfs into a universal Unicode/non-Unicode function or macro either didn't work (e.g. because of the L"..." wide-string prefix) or actually increased the number of code lines. So here it is in Spaghetti flavor. But at least it seems to work fine in a Windows command prompt. Please report back if the issue still persists somewhere.

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

Re: exhale - Open Source USAC encoder

Reply #713
You can make L prefixes for strings by going
#define somemacro(string) L##string

Or did that break?

Don't forget that if you're using the wchar_t / L"" variants of printf, you also need to supply wchar_t strings for all %s arguments.

Re: exhale - Open Source USAC encoder

Reply #714
Intel compiles of exhale-V1.1.4-d59780dc now at Rarewares. :)

Re: exhale - Open Source USAC encoder

Reply #715
Unicode bug has been fixed. Hooray!
P.S. There is a superfluous space in the timestamp.

@kode54 Windows Terminal is about Windows 10, the very OS I won’t use in the foreseeable future, no matter how hard the Silicon Valley hegemon tries to exhort.
• 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 #716
I think it's not a bug but an intention, formatting with fixed width font used in console ;)
--------------------

 

Re: exhale - Open Source USAC encoder

Reply #718
There is a superfluous space in the timestamp.
I think it's not a bug but an intention, formatting with fixed width font used in console ;)
Jup. Well, not really an intention here, but the predefined __DATE__ macro which I'm using for that purpose does it like that and isn't under my control.

You can make L prefixes for strings by going
#define somemacro(string) L##string
Oh cool, thanks a lot for that hint! With that I got a macro cleanup to work. Just committed that, rev. c3a9038 (see Update below). Note that, in that commit, I also fixed a minor issue with a double-backslash display ("ERROR while trying to open input file C:\\file") when the current working directory is a drive root, e.g., C:\. For some reason encoding still worked, though.

Update: I also committed kode54's extension of the make system now, adding support for building Mac Universal2 binaries by specifying UNIVERSAL2=1 when calling make. Please let me know if I committed the code proposal correctly.

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

Re: exhale - Open Source USAC encoder

Reply #719
@kode54 Windows Terminal is about Windows 10, the very OS I won’t use in the foreseeable future, no matter how hard the Silicon Valley hegemon tries to exhort.
Then buy some other third party terminal that does support Unicode and terminal formatting. And you may as well also buy extended support for your obsolete OS, to get a few more years out of it until you eventually switch to Linux.

Re: exhale - Open Source USAC encoder

Reply #720
Why exhale does scratches with every versions especially when it's slow? Does it need a powerful CPU, not a dual core with old archictecture? Sorry if it's offtopic. I have x5  speed on foobar2000


Re: exhale - Open Source USAC encoder

Reply #722
$ wc -c exhale*.exe | column -t
686080  exhale-john33.exe
1164800 exhale-netranger.exe

$ exhale 1 in.150M.wav out.m4a


timejohn33netranger
User 
Kernel  
Process 
Clock
20.982s
 1.684s
22.666s
22.820s
24.726s
 1.638s
26.364s
26.695s
Profiled with Procprofile 1.5.1 and (just in case you need a cross-platform tool with less verbose output) TimeIt  0.1.20160422.
• 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 #723
Why exhale does scratches with every versions especially when it's slow? Does it need a powerful CPU, not a dual core with old archictecture? Sorry if it's offtopic. I have x5  speed on foobar2000

For instance, I get 10x encode speed on my Ryzen 7 2700, but >150x decode speed using the foo_pd_aac component.

Re: exhale - Open Source USAC encoder

Reply #724
I believe you are right and broadcasters have new rules this year (see https://www.etsi.org/deliver/etsi_es/201900_201999/201980/04.02.01_60/es_201980v040201p.pdf)

Indeed, the DRM standard linked to by celona (thanks!) recommends PS only in the range 18 - 26 kbit/s (see sec. 5.4.3), and I second that recommendation.
Thank You both for pointing out!



Maybe I'll just ask Igor or a moderator to augment the first post of this thread to display a big "PLEASE READ THE FIRST 10 POSTS OF THIS THREAD FIRST BEFORE POSTING A QUESTION OR BUG REPORT!" sign?
@Chris, @kode54
Please feel free to edit the first post in any way You like.