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

Re: exhale - Open Source USAC encoder

Reply #450
Try to test 5.1 files, but foobar don't play it with decoder version 1.14. Can help?


Re: exhale - Open Source USAC encoder

Reply #452
Try to test 5.1 files, but foobar don't play it with decoder version 1.14. Can help?
Exhale isn't really meant to encode anything but mono or stereo, and FDK-AAC can't decode anything more than that from USAC streams at this point anyway.

Re: exhale - Open Source USAC encoder

Reply #453
I tried to compile Exhale (develop 6fe06fa7) with one of the new Apple Silicon M1 based Macs.

I got a working executable and no compilation errors but for the older 64bit platform; am I too optimistic to believe that adding the ARM64 platform is enough?


Re: exhale - Open Source USAC encoder

Reply #455
Warning, you have to modify src/lib/tempAnalysis.cpp as in commit 1281acbe.


Re: exhale - Open Source USAC encoder

Reply #457
For the record, the new commit can be considered a 1.1.0 beta version (increased SBR temporal resolution).

Warning, you have to modify src/lib/tempAnalysis.cpp as in commit 1281acbe.
That shouldn't be necessary anymore, the latest commit includes that fix.

Thanks very much, celona, for trying out ARM compilation. I have absolutely no experience with ARM or Mac platforms and currently no access to either of those, but in this thread at
https://hydrogenaud.io/index.php?topic=118888.msg984585#msg984585
some earlier, eventually successful attempts were documented.

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


 

Re: exhale - Open Source USAC encoder

Reply #459
For the record, the new commit can be considered a 1.1.0 beta version (increased SBR temporal resolution).

Warning, you have to modify src/lib/tempAnalysis.cpp as in commit 1281acbe.
That shouldn't be necessary anymore, the latest commit includes that fix.

Thanks very much, celona, for trying out ARM compilation. I have absolutely no experience with ARM or Mac platforms and currently no access to either of those, but in this thread at
https://hydrogenaud.io/index.php?topic=118888.msg984585#msg984585
some earlier, eventually successful attempts were documented.

Chris

Latest release compiles fine on aarch64/arm64 on FreeBSD 13-CURRENT

Code: [Select]
root@tsukihi:/usr/ports/audio/exhale # file /usr/local/bin/exhale
/usr/local/bin/exhale: ELF 64-bit LSB executable, ARM aarch64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 13.0 (1300124), FreeBSD-style, stripped
root@tsukihi:/usr/ports/audio/exhale # exhale -h
  ---------------------------------------------------------------------
 | exhale - ecodis extended high-efficiency and low-complexity encoder |
 |                                                                     |
 | version 1.0.8 (x64, built on Nov 19 2020) - written by C.R.Helmrich |
  ---------------------------------------------------------------------
Only issue is that it reports arch incorrectly, x64 isn't aarch64/arm :-)

Re: exhale - Open Source USAC encoder

Reply #460
I've quickly skimmed through a few albums.
I don't need to perform any  test to say that now exhale with a new SBR blows away everything I've heard at 48 kbps.  :-\  ::)  :-[

Re: exhale - Open Source USAC encoder

Reply #461
I've got these warnings when I used the seek bar of the foobar2000 v1.5.3.

Code: [Select]
File verification warning: Decoding error: Unsupported format or corrupted file, frame: 1095 of 7354
File verification warning: Decoding error: Unsupported format or corrupted file, frame: 1096 of 7354
I used http://www.rarewares.org/files/aac/exhale-develop-1.1a-6fe06fa7_x64.zip to encode.

Updating the fdk-aac packet decoder to the latest version, Version: 1.14, doesn't work.
Updating the foobar to v1.6.2 doesn't work.
It seems to happen on any music files encoded at exhale quality 0, 1, 2, 7.
Everything is fine if I don't touch the seek bar.

Re: exhale - Open Source USAC encoder

Reply #462
What's the difference between enhanced SBR and SBR? Is exhale using normal SBR?

Re: exhale - Open Source USAC encoder

Reply #463
I've got these warnings when I used the seek bar of the foobar2000 v1.5.3.
dev_1.1a_6fe06fa7 modes 0, a; fb2k_1.6.2; decoder_1.14; via wine: don't confirm

Re: exhale - Open Source USAC encoder

Reply #464
In comparison, exhale a sounds much, much better than fhgaacenc --vbr 1 (HE-AACv2). Keep up the good work!
--------------------

Re: exhale - Open Source USAC encoder

Reply #465
Thanks very much, Igor and capma!

Latest release compiles fine on aarch64/arm64 on FreeBSD 13-CURRENT
...
Only issue is that it reports arch incorrectly, x64 isn't aarch64/arm :-)
Thanks for checking and for the info! Can you tell me how I can complete the following code to print out "ARM" (regardless of whether it's 32-bit or 64-bit) instead of "x64" in your case?
Code: [Select]
#if (WHAT GOES HERE?) // ARM platform
    fprintf_s (stdout, "exhale %s.%s%s (ARM",
#elif defined (_WIN64) || defined (WIN64) || defined (_LP64) || defined (__LP64__) || defined (__x86_64) || defined (__x86_64__)
    fprintf_s (stdout, "exhale %s.%s%s (x64",
#else // 32-bit OS
    fprintf_s (stdout, "exhale %s.%s%s (x86",
#endif

I've got these warnings when I used the seek bar of the foobar2000 v1.5.3.
Code: [Select]
File verification warning: Decoding error: Unsupported format or corrupted file, frame: 1095 of 7354
File verification warning: Decoding error: Unsupported format or corrupted file, frame: 1096 of 7354
...
It seems to happen on any music files encoded at exhale quality 0, 1, 2, 7.
Everything is fine if I don't touch the seek bar.
Strange, I haven't seem that myself either since the first alpha. But I'll check again.

What's the difference between enhanced SBR and SBR? Is exhale using normal SBR?
Enhanced SBR has some more low-bit-rate tools inside which exhale doesn't implement (because they are not needed above 32 kbit/s stereo or so). If you're interested in details about these additional tools, see https://www.gel.usherbrooke.ca/gournay/documents/publications/JAES_V61_12_PG956.pdf sections 3.3.2 - 3.3.5.

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


Re: exhale - Open Source USAC encoder

Reply #467
With the next changes (maybe already next weekend) feel free to give it a listen at 36 and 48 kbit/s if you're so enthusiastic ;) And thanks for mentioning the average bit-rate you're getting, this is something I forgot to mention in my last post: I'm very much interested in what average bit-rates people get on their music collections even with this early SBR version.

Chris
I resumed my bitrate table (last tab):
https://docs.google.com/spreadsheets/d/18lGNoBB0ZB2A4SGAw3_z-5L7gzl54MG3D_V7tf2jII8/edit?usp=sharing

The computer will also run overnight. Two modes (a and c) are already completed: 39,1 kbps for music with a mode, and 56,9 kbps with c [6fe06fa7]. Audiobooks and stereo movies are even lower (32…34 kbps for a, and 50 for c).

Re: exhale - Open Source USAC encoder

Reply #468
__aarch64__ and __arm64__ --> 64-bit
__arm__ for 32-bit
Thanks a lot! I created a first release candidate of version 1.1.0, can you please check the latest revision of Git branch "develop" (5373500b and tell me if it works for you?

Two modes (a and c) are already completed: 39,1 kbps for music with a mode, and 56,9 kbps with c [6fe06fa7]. Audiobooks and stereo movies are even lower (32…34 kbps for a, and 50 for c).
Great, thanks. Looks OK to me. The latest revision (see above) includes some more SBR related fine-tunings for stereo and/or 48 kHz.

Btw, I also observed sporadic sound glitches when seeking through SBR enabled xHE-AAC files. Unfortunately, they can be quite loud. I currently have no idea whether this is an issue with the files generated by exhale or an issue with the packet decoder for foobar2000, and what the issue might be. So to give myself and others some more time to identify the issue, I'll tag a "final release candidate" of exhale 1.1.0 on Gitlab at the end of this month and wait with the final release until the end of the year.

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


Re: exhale - Open Source USAC encoder

Reply #470
__aarch64__ and __arm64__ --> 64-bit
__arm__ for 32-bit
Thanks a lot! I created a first release candidate of version 1.1.0, can you please check the latest revision of Git branch "develop" (5373500b and tell me if it works for you?
Hi,

Code: [Select]
version 1.1RC (ARM, built on Nov 21 2020) - written by C.R.Helmrich

Any reason why you decided not print 32 vs 64-bit like on x86?

Re: exhale - Open Source USAC encoder

Reply #471
Well, I have only 3 characters available (otherwise the header formatting would have to be changed), and I think all ARM versions since v8 from 2013 are 64-bit (are 32-bit versions still widely used?).

Btw, the exhale 1.1.0 RC1 gives identical results to 1.0.8 for all non-SBR modes when the input sampling rate is higher than 32 kHz. In case anyone is wondering whether they should already update.

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


Re: exhale - Open Source USAC encoder

Reply #473
For 1.0.8? So it's not an SBR related issue. Kamedo2 also provided some more details and a test encoding which confirms that. Here's the strange part: with my own compilation of exhale.exe (1.1RC) and the WAV file that he provided, I get the same bitstream (except for different timestamps in the MPEG-4 file header), and on both Windows 10 (version 2004) with foobar2000 1.5.6 and Windows 7 (SP1) with foobar2000 1.6.1, the files play perfectly, including seeking.  :o

So what are the differences between our software configurations? Are you guys using a newer version of Windows? Edit: Are you running the latest Windows update (20H2)? If not, do you have the 2020-11 cumulative update (KB4586781) installed? Both of those are not yet installed on my machine.

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

Re: exhale - Open Source USAC encoder

Reply #474
or, foo_verifier buggy