Skip to main content ↑ ↓

Notice

If you are using a Hotmail or Outlook email address, please change it now, as Microsoft is rejecting all email from our service outright.
Topic: exhale - Open Source xHE-AAC encoder (Read 58548 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: exhale - Open Source xHE-AAC encoder

Reply #475 –
Quote from: alter4 on
Can confirm decoding issues in Foobar2000 while seeking with integrity verifier enabler for 1.0.8
Quote from: m14u on
or, foo_verifier buggy
Option "Verify integrity of played tracks and report error immediately" and this  error on seeking have nothing to do with foo_verifier.

Re: exhale - Open Source xHE-AAC encoder

Reply #476 –
Quote from: C.R.Helmrich on
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.
Have you enabled File->Preferences->Playback->Verify integrity of played tracks and report errors immediately?
I use fb2k 1.6.2 on windows 7 and error is presented.

Re: exhale - Open Source xHE-AAC encoder

Reply #477 –
yes.
with enabled "Verify integrity [...]" option this error confirmed

Re: exhale - Open Source xHE-AAC encoder

Reply #478 –
Since foo_pd_aac is involved, we probably need @kode54 to look into this error

Re: exhale - Open Source xHE-AAC encoder

Reply #479 –
Oh, thanks for the info about that checkbox. Yes, now I get that error too on some seeks (not all, though), even with the files created with exhale 1.0.7 (and possibly all earlier versions). Yes, since xHE-AAC does not allow random access in every frame like AAC, I'd kindly ask Peter and kode54 to take a look at the decoder component.

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

Re: exhale - Open Source xHE-AAC encoder

Reply #480 –
I already know there is no seeking accuracy. In fact, there isn't even any decoding consistency between any two given full decode runs of FDK-AAC. If someone wants to write a USAC decoder that produces consistent results and supports proper seeking, they're welcome to start from scratch, E: as FDK-AAC is literally the only open source USAC decoder in existence right now, all other solutions are proprietary decoder libraries that are often tied to the operating system.

Re: exhale - Open Source xHE-AAC encoder

Reply #481 –
Quote from: C.R.Helmrich on
Oh, thanks for the info about that checkbox. Yes, now I get that error too on some seeks (not all, though), even with the files created with exhale 1.0.7 (and possibly all earlier versions). Yes, since xHE-AAC does not allow random access in every frame like AAC, I'd kindly ask Peter and kode54 to take a look at the decoder component.

Chris

Check in my home with exhale-develop-1.1a-6fe06fa7_x64 all is right with option "a" (SBR) and vbr format include (great)
Check with foobar and win 7 (no sp1)
Two questions

1 You adds PS (Parametric stéro) function in your project ? (great this)   8)

2 for input formats, possible adds directly Flac format Because wav format is old, flac is used for many's  players, and many people have audio in this format (flac)

Regards,

Re: exhale - Open Source xHE-AAC encoder

Reply #482 –
You're right, kode54, and as long as I don't use that "verify integrity" checkbox and don't seek much (during usual casual listening, that is), it's not really much of a problem. I'm happy that I can listen to xHE-AAC files at all in foobar2000.

Quote from: Jpt on
1 You adds PS (Parametric stéro) function in your project ? (great this)   8)
No, as I wrote several times (starting at https://hydrogenaud.io/index.php?topic=118888.msg980837#msg980837), that's too much work for me.
Quote
2 for input formats, possible adds directly Flac format Because wav format is old, flac is used for many's  players, and many people have audio in this format (flac)
No, but to encode directly from FLAC (or other formats) you can use foobar2000 (https://gitlab.com/ecodis/exhale#third-party-stdin-foobar2000) or e.g. Moisés Cardona's exhale GUI with FFmpeg (https://moisescardona.me/?s=exhale).

Edit: Thanks again, guruboolez, for the link to your bit-rate table!
Quote from: guruboolez on
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).
I noticed in your results that, with SBR, exhale tends to undercode "noisy" music (like metal). I just found the reason for this behavior (some code was active only with 48 kHz but not with 44.1 kHz input) and fixed it. This affects modes b-g when the input sampling rate is 44.1 kHz. So could you please be so kind and rerun your script for modes b and c? O:) Mode a and all modes fed with 48-kHz audio should not be affected.

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

Re: exhale - Open Source xHE-AAC encoder

Reply #483 –
Quote from: C.R.Helmrich on
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

You have a lot of devices still on 32-bit, that includes RPi (not all) and pretty much the complete range of Amazon tablets etc not to mention SoCs that doesn't target cheap as chips market like IMX-series etc or simply LTS.

Re: exhale - Open Source xHE-AAC encoder

Reply #485 –
Might be 'jumping the gun' here ( :D ) but Intel compiles of exhale-develop-1.1rc2-f1d66fb3 are below.

www.rarewares.org/files/aac/exhale-develop-1.1rc2-f1d66fb3_x64.zip

www.rarewares.org/files/aac/exhale-develop-1.1rc2-f1d66fb3_x86.zip

Re: exhale - Open Source xHE-AAC encoder

Reply #486 –
Quote from: C.R.Helmrich on
I noticed in your results that, with SBR, exhale tends to undercode "noisy" music (like metal). I just found the reason for this behavior (some code was active only with 48 kHz but not with 44.1 kHz input) and fixed it. This affects modes b-g when the input sampling rate is 44.1 kHz. So could you please be so kind and rerun your script for modes b and c? O:) Mode a and all modes fed with 48-kHz audio should not be affected.

Chris
Some RC2 modes are now completed. I only did some albums with a mode, and resulting bitrate is indeed always identical between beta 6fe06fa7 and RC2. Therefore I have four RC2 results in my table: a-b-c-d.
Average bitrate for music are:
mode amode bmode cmode d
39.1 kbps50.1 kbps59,0 kbps76,6 kbps
——+ 11,0 kbps+ 8,9 kbps+17,6 kbps

I don't know if it's easily feasible or not but I think that current presets should be better balanced. There's a big gap between mode c and mode d (60 → 76 kbps).  But the gap is twice shorter between mode b and mode c (50 → 59 kbps). Assuming that RC1 and RC2 are similar, the gap between d → e ≈ 9 kbps and e → f ≈ 15 kbps.

Or is it intended?

EDIT: thanks John33 for the binaries :)

Re: exhale - Open Source xHE-AAC encoder

Reply #487 –
I have very close numbers to what Guru mentions.
I see that  SBR bitrates are 36+n*12 kbps and   I think humanity gets used to 48/64/80 kbps  :)
It's also worth to mention that HE-AAC's  SBR was useful up to ~72 kbps ... so maybe 48/64/72.

Anyway current formula 36+n*12 works  fine too.


Re: exhale - Open Source xHE-AAC encoder

Reply #488 –
Thanks, guruboolez and Igor! You're right, that was close, but not quite what I intended. Indeed, what I wanted was a constant difference of around 11 kbit/s between the SBR modes (for stereo, a bit more at high rates, a bit less at low rates), so something like:

mode amode bmode cmode d
39 kbps49 kbps60 kbps72 kbps
——+10 kbps+11 kbps+12 kbps

and so on for the higher modes. I just finished a (hopefully) final RC (7f47aaab) which fixes a rare bit-rate allocation bug for very loud noise-like audio (infamous GloriousTimes sample here on HA, for example) and packs the SBR data a bit more efficiently. With that version, CVBR modes a and b should now be very close to the above target rates, and I retuned the bit-rates for modes c and d to match the target rates (60 and 72 kbit/s, respectively) more closely.

By the way, since the previously discussed seeking issues were found not to be caused by exhale and I have only one more minor issue on my to-do list, I might actually be able to make a final 1.1.0 release of exhale on the weekend :)

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

Re: exhale - Open Source xHE-AAC encoder

Reply #489 –
Maybe I'm already dreaming, before tonight I have compiled Exhale without errors for Apple Silicon.

I attach the obtained ARM64 file which works perfectly.

Tonight I have compiled the Exhale commit 7f47aaab for macOS x86_64 with no problems.

Now compiling for ARM64 (Apple Silicon M1) from Exhale commit 7f47aaab I get the following errors.

% make release

/Library/Developer/CommandLineTools/usr/bin/make -C src/lib  release MM32=0
/Library/Developer/CommandLineTools/usr/bin/make -C src/app  release MM32=0
g++ -o ../../bin/exhale -Wall   ../../build/basicMP4Writer.r.o ../../build/basicWavReader.r.o ../../build/exhaleApp.r.o ../../build/exhaleAppPch.r.o ../../build/loudnessEstim.r.o -L../../lib -ldl -lpthread -lexhale
ld: warning: ignoring file ../../build/basicMP4Writer.r.o, building for macOS-arm64 but attempting to link with file built for unknown-x86_64
ld: warning: ignoring file ../../build/basicWavReader.r.o, building for macOS-arm64 but attempting to link with file built for unknown-x86_64
ld: warning: ignoring file ../../build/exhaleApp.r.o, building for macOS-arm64 but attempting to link with file built for unknown-x86_64
ld: warning: ignoring file ../../build/loudnessEstim.r.o, building for macOS-arm64 but attempting to link with file built for unknown-x86_64
ld: warning: ignoring file ../../lib/libexhale.a, building for macOS-arm64 but attempting to link with file built for macOS-x86_64
ld: warning: ignoring file ../../build/exhaleAppPch.r.o, building for macOS-arm64 but attempting to link with file built for unknown-x86_64
Undefined symbols for architecture arm64:
  "_main", referenced from:
     implicit entry/start for main executable
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [../../bin/exhale] Error 1
make: *** [release] Error 2

I'm going to sleep and tomorrow I'll try to figure out what I did wrong. I just remember compiling after the command:
export ARCHFLAGS='arch arm64'

Re: exhale - Open Source xHE-AAC encoder

Reply #490 –
I'm an idiot. I closed Terminal and did it all over again, now it works in every 64bit Mac.

exhale_ 7f47aaab_arm64.zip (109.01 KB)

exhale_ 7f47aaab_x86_64.zip (119.04 KB)

exhale_ 7f47aaab_fat_arm64_x86_64.zip (228.03 KB) [This fat binary contains both versions and run in every 64bit Mac]

  ---------------------------------------------------------------------
 | exhale - ecodis extended high-efficiency and low-complexity encoder |
 |                                                                     |
 | version 1.1RC (ARM, built on Nov 25 2020) - written by C.R.Helmrich |
  ---------------------------------------------------------------------

 Copyright 2018-2020 C.R.Helmrich, project ecodis. See License.htm for details.

 This software is made available under the exhale Copyright License and comes
 with ABSOLUTELY NO WARRANTY. This software may be subject to other third-party
 rights, including patent rights. No such rights are granted under this License.

 Usage:   exhale preset [inputWaveFile.wav] outputMP4File.m4a

 where

 preset   =  # (0-9)  low-complexity standard compliant xHE-AAC at 16*#+48 kbit/s
         (a-g)  low-complexity compliant xHE-AAC with SBR at 12*#+36 kbit/s

 inputWaveFile.wav  lossless WAVE audio input, read from stdin if not specified

 outputMP4File.m4a  encoded MPEG-4 bit-stream, extension should be .m4a or .mp4


 Notes:   The above bit-rates are for stereo and change for mono or multichannel.
    Use filename prefix ./ for the current directory if this executable was
   called with a path (call: /Users/christian/Downloads/exhale).

Re: exhale - Open Source xHE-AAC encoder

Reply #492 –
Quote from: C.R.Helmrich on
With that version, CVBR modes a and b should now be very close to the above target rates, and I retuned the bit-rates for modes c and d to match the target rates (60 and 72 kbit/s, respectively) more closely.

Quote from: john33 on
And here are Intel compiles of exhale-develop-1.1rc3-7f47aaab:
:)

Mode a to d with RC3 are baking  ;)

Re: exhale - Open Source xHE-AAC encoder

Reply #493 –
I just discovered something…
I tried one hour ago a storage service named pCloud (it's a Dropbox/Onedrive-like service). Interesting features (you can buy a lifetime plan,  expensive but discounted for Black Friday). The Android App also includes a basic audio player for streaming purpose. The service claims FLAC and MP3 support, but no mention for something else, which is a bit strange. So after I created my free demo account (few Gb free) I upload an LC-AAC file: playback is fine but tags are apparently not supported (it's my first steps in the service—I could be wrong here).

Just for fun, I uploaded an USAC file (freshly created from RC3, with mode a which means SBR) which has the same container/file extension (m4a). Upload is fine of course, and I tried to guess what kind of error message I'll get on playback. I'm nearly shocked but it works! I checked many times to be sure I didn't make a mistake, but no, eXhale's encodings are playing fine! Seeking is also working (I didn't hear any glitch). No gapless, no album art, no tags, it's very basic. I also sent a full album (<15 Mb  O:) ) and it's fine!

The app probably uses system decoders (Android 9 on my side: USAC is natively supported).

After this discovery I tried with Dropbox, Google Drive and Onedrive: none have audio streaming so it doesn't work.
So if you want to expand the storage capacity of your phone/tablet and try exhale, you can take a look at this service :)


EDIT : it also works with Opus with *.ogg extension.

Re: exhale - Open Source xHE-AAC encoder

Reply #494 –
Interesting, haven't heard of that service! And thanks for another round of baking ;) I noticed the a and b results are almost complete and look good.

To all developers: I found a rare issue with exhale when running CVBR mode a on 32-kHz input, see https://gitlab.com/ecodis/exhale/-/issues/16
I don't think this is a showstopper for the upcoming release (since it only seems to happen with sampling rates lower than what people should be using), but it might indicate a deeper issue, so it would be great if people familiar with code checkers (e.g., Valgrind) could assist me in figuring out what goes wrong during the last quarter of that WAV sample when encoding it with mode a.

To everyone: if you ever come across an xHE-AAC file generated by exhale which causes error messages during playback or conversion in e.g. foobar2000 (with kode54's FDK-AAC packet decoder), please save that file and let me know! Either here or by filing an issue on Gitlab.

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

Re: exhale - Open Source xHE-AAC encoder

Reply #496 –
Quote from: guruboolez on
Therefore I have four RC2 results in my table: a-b-c-d.
Average bitrate for music are:
mode amode bmode cmode d
39.1 kbps50.1 kbps59,0 kbps76,6 kbps
——+ 11,0 kbps+ 8,9 kbps+17,6 kbps


Update RC3:

mode amode bmode cmode d
38,4 kbps49,5 kbps60,5 kbps73,1 kbps
——+ 11,1 kbps+ 11,0 kbps+12,6 kbps

Balance between SBR presets is now much better with RC3! Congratulation  :)

Re: exhale - Open Source xHE-AAC encoder

Reply #497 –
Good to see RC3 hitting target bitrates

I've noted that SBR produces better quality at least for some samples when a source is 48 kHz (generally because higher sampling rate allows slightly higher no-SBR frequency range before SBR starts its range) . Anyway it's very fast observation and I hadn't time to test it in depth.


Re: exhale - Open Source xHE-AAC encoder

Reply #498 –
The RC3 SBR table is now completed (1700 hours of encoded music for 7 presets!):

mode amode bmode cmode dmode emode fmode g
AVERAGE38,4 kbps49,5 kbps60,5 kbps73,1 kbps85,497,4112,3
————+11,1 kbps+11,0 kbps+12,6 kbps+12,3 kbps+12,0 kbps+14,9 kbps
BILLBOARD39,6 kbps51,4 kbps62,9 kbps75,4 kbps87,198,2112,6
BEST-SELLING39,1 kbps50,3 kbps61,2 kbps72,4 kbps84,596,3111,7
CLASSICAL36,5 kbps45,8 kbps56,1 kbps69,8 kbps82,597,1111,8
JAZZ38,1 kbps49,2 kbps61,0 kbps75,7 kbps88,699,0114,2
METAL37,1 kbps48,2 kbps58,7 kbps68,5 kbps81,093,6109,2
ELECTRONIC40,2 kbps51,8 kbps63,4 kbps76,5 kbps88,7100,1114,7
   




Re: exhale - Open Source xHE-AAC encoder

Reply #499 –
awesome work on the huge encoding task and results to help dev, guruboolez  :)
 
SimplePortal 1.0.0 RC1 © 2008-2021