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 304528 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: exhale - Open Source USAC encoder

Reply #725
Notice added, as was exactly suggested by Chris.

New binaries with the minor Unicode change, which doesn't affect macOS builds anyway, but whatever.

https://f.losno.co/exhale-v1.1.4-3-gcc4151b.zip

Timing information from various machines:

Dad's iMac: Intel(R) Core(TM) i5-4570R CPU @ 2.70GHz / 8GB RAM
MBP: Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz
Mac mini: Apple M1

timeDad's iMacMBPMac mini (Rosetta)Mac mini (Native)
User 
System  
CPU 
Total
244.57s
3.58s
99%
4:08.21
230.15s
4.58s
99%
3:55.41
161.82s
5.62s
96%
2:54.23
132.07s
5.24s
94%
2:25.47
Corpus: Hiroki Kikuta - Secret of Mana+
Duration: 00:49:26.89
Sample rate: 44100Hz
Sample format: 16 bit
Channels: stereo
Audio MD5: 02F7A079C8D1B037C111162FA3B4CDBF

Command line: exhale 1 01\ -\ Secret\ of\ Mana.wav 01\ -\ Secret\ of\ Mana.m4a

Re: exhale - Open Source USAC encoder

Reply #726
Notice added, as was exactly suggested by Chris.
Thank You.

I am planning a personal listening test of the latest exhale and the Opus encoder.
Exhale will be tested with and without the SBR.
If nothing is wrong, I'm going to start testing from 2021/04/03.

Below is the bitrate table of the tested samples in bps.
Code: [Select]
length[sec]	exhale.c.64k	exhale.1.64k	opus.62k	exhale.e.88k	exhale.2.80k	opus.80k	filename
28.302449 81199 80218 73541 104028 96833 95249 10xh_.wav
11.878571 58106 70776 82934 82409 85669 103687 11ff_.wav
8.252063 67404 76656 70562 93430 93945 90624 12at_.wav
10.030998 68502 72969 67597 90542 88539 86942 13by_.wav
15.000771 69271 72271 83964 95502 89230 107602 14fe_.wav
29.206599 64635 77163 65405 87770 90984 83760 15ma_.wav
8.252063 61219 63194 67762 84183 77129 84811 16mb_.wav
11.878571 71365 75570 73479 97155 91817 94913 17qu_.wav
15.471701 72109 84782 72357 95125 99839 92233 18vr_.wav
30.291701 67653 70099 72197 94803 85964 92551 19am_.wav
30.000023 65889 70826 63895 88973 85863 83000 20tt_.wav
19.187347 68295 74314 72916 92831 90621 93070 21wa_.wav
29.908549 67638 69377 67815 92090 84703 86549 22ex_.wav
11.902381 63394 70436 67855 83817 85528 87487 23ht_.wav
19.144354 64523 69441 68512 90219 85566 82994 24td_.wav
24.493991 69405 76047 78994 94019 90768 103220 01 castanets.wav
20.004422 79211 89677 90460 100253 104521 117074 02 fatboy_30sec.wav
17.468027 75990 78370 82867 107020 95468 107081 03 eig.wav
20.38093 68243 87039 86735 87674 104426 109700 04 Bachpsichord.wav
28.230771 64572 72773 69926 86566 88835 89108 05 Enola.wav
10.329887 57987 69040 83625 87132 85543 106781 06 trumpet.wav
25.097959 72506 75534 75347 97080 92273 95983 07 applaud.wav
29.018934 86717 75998 69710 109027 92649 91347 08 velvet.wav
20.154921 62957 61911 59436 85728 76115 75877 09 Linchpin.wav
20.006735 65768 77281 75511 87071 91216 95042 10 spill_the_blood.wav
28.405918 59437 55188 56687 85110 70100 67418 11 female_speech.wav
19.858322 69985 69321 73034 95719 85483 93052 12 French_Ad.wav
20.07996141 68295.55556 73565.59259 73078.62963 92417.62963 89245.44444 93227.96296 27_TESTED_SAMPLE_TRACKS_AVERAGE

300 61085 66806 63464 85342 81479 81510 Album Average
Great! That will be very useful as we're strongly agree that SBR must be used at 48 kbps, though it's not clear if it should be at 60-80 kbps.

Only one thing to comment. No-SBR exhale mode 1 (~64 kbps) will require resampling to 32 kHz. foobar2000's dbpoweramp/SSRC resampler or SoX VHQ + 99% passband are the ones which preserve almost all frequencies, extremely close to 16 kHz and should be used for both, encoding and decoding, during a prep of files for ABX sessions.   I've used SoX VHQ + 99% passband in previous test https://hydrogenaud.io/index.php?topic=119227.0
and https://hydrogenaud.io/index.php?topic=118888.msg983108#msg983108

Re: exhale - Open Source USAC encoder

Reply #727

  samples             exhale 1 32kHz   exhale 1 44kHz   opus vbr 64     flac      
 ------------------- ---------------- ---------------- ---------------- ----------------
  George Michael      235 602          231 870          232 397          3 637 717 
  Loreena McKennitt   272 783          269 062          277 449          3 513 477 
  Øystein Sevåg       229 935          238 929          293 827          2 753 136 


@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.

Windows 7 is stable enough to serve daily needs for at least another 5–10 years, Unicode usually works as expected, patches are coming unofficially. Even XP is still sturdy thanks to the community efforts. Those needs exclude GPU-hungry games, and if one wants to play, there are indie gems and ScummVM & Dosbox wrappers to run soulful retro ones. As a side effect, this allows to escape the digital pollution of nowadays with gargantuan Electron-based junk like Signal Desktop (insane 2109 folders with 17862 files on disk and 350 MiB in memory seem to be acceptable for security LARPers). As for Linux-Tux, I tried that less traveled road soon after ██████ sent me a CD. It led me to a labyrinthine quagmire of incoherence between heterogeneous objects wrapped with a duct tape in a Sisyphean way. Go figure! But my LEGO days are long behind, not to mention less tolerance of verbose manuals that veil a lack of compassion for users people. This may induce an image of some hairy preacher eccentric like Richard Stallman, yet “there are more things in heaven and earth, Horatio, than are dreamt of”. Indeed, there is a plethora of seasoned folks who are immune to bulldozing by end-of-life mantras of rentier capitalism and refuse to support the planned obsolescence, as Victor Papanek would say. Deus ex machina apps, such as Exhale, postpone upgrades and reduce costs by enabling us to allocate resources more efficiently without harming our perception and environment that much, thus they fit perfectly into an eco-friendlier mindset.

Now, back to squeezing, enjoy!
• 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 #728
Great! That will be very useful as we're strongly agree that SBR must be used at 48 kbps, though it's not clear if it should be at 60-80 kbps.

Only one thing to comment. No-SBR exhale mode 1 (~64 kbps) will require resampling to 32 kHz. foobar2000's dbpoweramp/SSRC resampler or SoX VHQ + 99% passband are the ones which preserve almost all frequencies, extremely close to 16 kHz and should be used for both, encoding and decoding, during a prep of files for ABX sessions.   I've used SoX VHQ + 99% passband in previous test https://hydrogenaud.io/index.php?topic=119227.0
and https://hydrogenaud.io/index.php?topic=118888.msg983108#msg983108

Thanks for the info!
I am currently having no trouble using exhale mode 1 in 44kHz, and I am going to test mode 1 in both the 32kHz and 44kHz.
I'm going to use refalac to the 32kHz <-> 44kHz conversion, because it is a known good resampler, and it supports floating point natively.

Code: [Select]
qaac_2.71\x64\refalac64 in.wav --rate 32000 -D -b 32 -o in-32kHz.wav

exhale-V1.1.4-cc4151b9_x64\exhale c in.wav out.c.64k-44kHz.mp4
exhale-V1.1.4-cc4151b9_x64\exhale e in.wav out.e.88k-44kHz.mp4
exhale-V1.1.4-cc4151b9_x64\exhale 1 in.wav out.1.64k-44kHz.mp4
exhale-V1.1.4-cc4151b9_x64\exhale 1 in-32kHz.wav out.1.64k-32kHz.mp4
exhale-V1.1.4-cc4151b9_x64\exhale 2 in.wav out.2.88k-44kHz.mp4

// here use foobar2000 GUI manually to convert the xHE-AAC into wav.

qaac_2.71\x64\refalac64 out.1.64k-32kHz.wav --rate 44100 -D -b 32 -o out.1.64k-32kHz-44kHz.wav



Re: exhale - Open Source USAC encoder

Reply #731
Also missed that I benchmarked my same build on multiple Macs, and how soundly the M1 kicks a fairly high end Haswell's ass even in emulation.

Re: exhale - Open Source USAC encoder

Reply #732
Something that would be interesting to compare between builds would be if they generate the same result of if you get rounding errors etc in the more optimized variants. Just because something compiles and runs doesn't mean it does the correct "thing" :-)

Re: exhale - Open Source USAC encoder

Reply #733
I compared the macOS outputs from Intel Mac, M1 on Rosetta, and M1 Native. They only differ by the timestamp fields in the MP4 container, and not by any of the bitstream data.

Re: exhale - Open Source USAC encoder

Reply #734
Notice added, as was exactly suggested by Chris.

New binaries with the minor Unicode change, which doesn't affect macOS builds anyway, but whatever.
Thanks very much for both. Theoretically, I could have produced a typo in the non-Windows source code during my macro cleanup, so the compile check on Mac is much appreciated.

I also get identical (disregarding the timestamps in the MPEG-4 file header) encoded files with NetRanger's gcc build and my own VS2012 build (both x64). IIRC, the Intel compiler may, due to other optimizations, produce slightly different encodings which, however, should sound the same.

Edit: forgot to reply to
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?
https://gitlab.com/ecodis/exhale/-/wikis/faq#why-is-the-exhale-encoder-so-slow-is-there-a-switch-for-fast-encoding

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

Re: exhale - Open Source USAC encoder

Reply #735
Hey! I wanted to update that compatibility with (at least) my Samsung A50 has been resolved - now I can seek inside song without any errors. Samsung Music player. Last time I tried with, I think, 1.0.3 and it played, but as soon as I tried to seek it would error out and skip to next song.
Error 404; signature server not available.


Re: exhale - Open Source USAC encoder

Reply #737
thanks for the wiki. but i meant audio scratches. with NetRanger builds usually is not audible. is exhale fault or my pc fault that uses older instructions so the problem is how it was compiled?

Re: exhale - Open Source USAC encoder

Reply #738
Does the USAC standard supports as metadata and covert art/thumbnail a Jpeg XL faster decoding 4 file? Do you think they will support new JPEG?
-d 1.541 -s 7 --epf=3 --gaborish=1 --noise=1 --intensity_target=210 --dots=0 --faster_decoding=4
the 50° commit:  jpeg xl a1248445


Re: exhale - Open Source USAC encoder

Reply #739
A look at the spectrogram of that file tells me that it was not created by exhale. https://www.poikosoft.com/music-converter-encoder-versions seems to confirm that, it lists a Fraunhofer xHE-AAC encoder. Interesting :)

Hey! I wanted to update that compatibility with (at least) my Samsung A50 has been resolved - now I can seek inside song without any errors. Samsung Music player. Last time I tried with, I think, 1.0.3 and it played, but as soon as I tried to seek it would error out and skip to next song.
Great news, thanks very much for sharing this information!

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

Re: exhale - Open Source USAC encoder

Reply #740
A look at the spectrogram of that file tells me that it was not created by exhale. https://www.poikosoft.com/music-converter-encoder-versions seems to confirm that, it lists a Fraunhofer xHE-AAC encoder. Interesting :)

They want to force me to use Windows :) Now I'm going to try it out, I bought it some time ago from Poikosoft.

Re: exhale - Open Source USAC encoder

Reply #741
It's great to the point of buying a new license from the developer. Paolo Balestri's male voice is reproduced much better even at 24kbps in CBR mode.

However, below 40kbps it reduces the sampling frequency in VBR, while in CBR it reduces it to extremely lower bitrates, I also tried 8kbps (even 6kbps but there is too much noise).

Re: exhale - Open Source USAC encoder

Reply #742
Indeed, that encoder demonstrates xHE-AAC's full speech coding potential at low bit-rates. Attached a comparison with exhale mode 'a' at 24 kbps, 44.1 kHz sampling rate. Impressive improvement due to the ACELP speech coding core, which exhale doesn't have. Yes, VBR0 and VBR1 are coded at 38.4 kHz with Fraunhofer's encoder, it seems, so my demo was also made with CBR mode.

Chris

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

Re: exhale - Open Source USAC encoder

Reply #743
It is strange but also the behavior of the Fraunhofer encoder is not very predictable. In your examples Foobar reports the use of SBR only for Exhale. Compressing at higher bitrates with the Fraunhofer encoder sometimes produces worse results and files are resampled to 32kHz or 38.4kHz.

I believe that in VBR at bitrates higher than 48kbps (or perhaps only higher than 40kbps, obviously referring to monophonic signals) you don't get great advantages from ACELP.

I would like to thank Poikosoft for providing the cheapest way of obtaining the Fraunhofer encoder on the market by even providing it as a free upgrade to previous customers, a behavior that I wanted to reward by buying their software again, and will surely get more orders in the future from my employer, because buying his software is the best way to be able to distribute content in Extended HE-AAC and avoid any disputes. I had bought it to distribute compressed audio with Exhale in the past.

With the Fraunhofer encoder I can keep the voice taking up about half the space compared to Exhale. The entry I gave as an example, but also the ones in Helmrich's file seem to feel better at 24kbps than at 40kbps when compressed with Exhale.

Going up with the bitrate, on the other hand, the two compressors apparently offer approximately the same yield.

Re: exhale - Open Source USAC encoder

Reply #744
I think the selected encoder sample rates are tuned for best audio quality.

Celona, Christian: I am able to build the encoder that gives 44.1kHz and 48 kHz for the whole bit rate range.

Re: exhale - Open Source USAC encoder

Reply #745
What I don't understand is why if I keep 48kHz at 24kbps, raising the bitrate will resample my files to a lower rate. This behavior is difficult to predict, but the result is how you write probably better.

Re: exhale - Open Source USAC encoder

Reply #746
What I don't understand is why if I keep 48kHz at 24kbps, raising the bitrate will resample my files to a lower rate. This behavior is difficult to predict, but the result is how you write probably better.

Please explain. Or email me. 😀

Re: exhale - Open Source USAC encoder

Reply #747
I think the selected encoder sample rates are tuned for best audio quality.

Celona, Christian: I am able to build the encoder that gives 44.1kHz and 48 kHz for the whole bit rate range.
I don't want to tell you how to configure an encoder which I didn't develop, you should definitely check back with Fraunhofer as the original developers. But I assume that, since CBR 24-kbps mono coding sounds fine to my ears, VBR1 mono coding (~32 kbps target according to EZ CD Audio Converter) and all higher VBR modes should be able to handle 44.1 kHz sampling rate.

Not sure about the stereo target modes, however, I haven't checked those yet. But they might be fine already.

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

 

Re: exhale - Open Source USAC encoder

Reply #748
Please explain. Or email me. 😀
I'm asking myself the problem of not being in the proper thread, because we're talking about another encoder here. Tonight I tried all the possible combinations, but let's start with the simplest thing, the VBR mode.

The encoder performs very well. I used the usual 5s from male voice of Paolo Balestri where the defects is more evident until now and the only verification I can ask you is to check that the VBR "32kb/s" label shown in the graphic interface of EZ CD Audio converter is correct.

I leave you the files used for the tests so that you can reproduce what I write - it is the scientific method :)

In input we have a mono file sampled at 48kHz: paolo.balestri-23lufs-m-48k.wav (-23 LUFS like EBU R128 - to check because I was tired).

After compression in I get the following results:
paolo.balestri-23lufs-m-48k-vbr-12kbps.m4a @ 12kbps VBR setting – USAC with SBR, 12.9KB, 18kbps, 32kHz;
paolo.balestri-23lufs-m-48k-vbr-32kbps.m4a @ 32kbps VBR setting – USAC with SBR, 13.3KB, 18kbps, 38.4kHz;
paolo.balestri-23lufs-m-48k-vbr-40kbps.m4a @ 40kbps VBR setting – USAC without SBR, 31KB, 46kbps, 48kHz;
paolo.balestri-23lufs-m-48k-vbr-56kbps.m4a @ 56kbps VBR setting – USAC without SBR, 28.9KB, 43kbps, 48kHz;
paolo.balestri-23lufs-m-48k-vbr-72kbps.m4a @ 72kbps VBR setting – USAC without SBR, 35.2KB, 53kbps, 48kHz;
paolo.balestri-23lufs-m-48k-vbr-104kbps.m4a @ 104kbps VBR setting – USAC without SBR, 53.5KB, 83kbps, 48kHz;
paolo.balestri-23lufs-m-48k-vbr-136kbps.m4a @ 136kbps VBR setting – USAC without SBR, 71.9KB, 113kbps, 48kHz.

As you can see, the first two results have very similar bitrates and this offers no advantage. Furthermore, the 54kbps setting produces smaller files than the 40kbps setting and this can confuse the user who will not be able to predict how much he will get from the software.

A hypothetical problem to be verified: what would the user get who has the computer connected via USB to an external DAC that does not support 38.4kHz chosen as resampling? We should try what we get not only with Windows but also with other OS (and with many USB gadgets) and testing with Bluetooth or Wi-Fi speakers connected too (but in the latter case I don't foresee any problems). Assuming to resample at 44.1kHz as suggested by C.R. Helmrich would brush aside these doubts and diversify the bitrate obtained with different options.

On the constant bitrate tests I found more problems but I will write about it in the future. For now I will limit myself to offering you just an example to show you how the first two options produce a result similar to 24kbps CBR, which however you have chosen to keep at the sampling rate provided in input and the result is good.

paolo.balestri-23lufs-m-48k-cbr-24kbps.m4a @ 24kbps CBR setting – USAC without SBR, 17KB, 24kbps, 48kHz.

I have informed the author of the misuse I am making of its contents; I tried to compress one of his podcast with 12 min music and voice. in just 2 MB. In the future I will also try in stereo. The already compressed original was downloaded from here: https://youtu.be/FJkP7Ru-or0.

podio_dei_campioni-vbr-12kbps.m4a @ 12kbps VBR setting – 2MB;
podio_dei_campioni-cbr-24kbps.m4a @ 24kbps CBR setting – 2MB;
podio_dei_campioni-vbr-32kbps.m4a @ 32kbps VBR setting – 2MB;
podio_dei_campioni-vbr-40kbps.m4a @ 40kbps VBR setting – 5MB;
podio_dei_campioni-vbr-56kbps.m4a @ 56kbps VBR setting – 5MB.

Again the first 3 options and the last 2 produce almost identical results.