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

Re: exhale - Open Source USAC encoder

Reply #600 –
Do you still have compiles for windows for exhale-develop-1.1.0rc4-c71ec480? Which bitrate is stereo SBR (d preset) for that commit?

Re: exhale - Open Source USAC encoder

Reply #602 –
From the tests I did exhale works practically everywhere, below I leave you the binary (last commit) for Linux on armv6l:
exhale.gz - update: download video.

From a practical standpoint it means that your router or powerline adapter could compress a monaural audio file into about 50% of its playing time. I have no ideas about possible uses, but these SBCs cost very little, in Europe they can be bought for less than 6 euros including taxes and perhaps one of the easiest to find is the Raspberry PI Zero, with 1GHz single-core CPU, 512MB RAM and works also as a USB gadget.

These are SoC very popular in the past, the armv6 architecture is the same as the first iPod touch, the first iPhone, the second and 3G too.

Re: exhale - Open Source USAC encoder

Reply #603 –
Quote from: C.R.Helmrich on
Compared to NetRanger's last RC, there is only a slight stabilization for strongly out-of-phase input (which should occur very rarely, if at all) at CVBR modes 5 and above.

Nowadays lots of Stereo-sources are Dolby-Surround coded, which means that all back facing sounds are 180° phase shifted between L an R channels.
So I really doubt that out of phase contents are a rare condition. They are commonplace.

Re: exhale - Open Source USAC encoder

Reply #604 –
Must be really fun listening to crap like that on headphones, like I usually do.

Re: exhale - Open Source USAC encoder

Reply #605 –
Indeed. scharfis_brain, is Dolby Surround encoded stereo audio still really that commonplace? The last audio CD in my collection on which I saw that (German band Schiller) is 20 years old.

I just released a relatively urgent release candidate of exhale 1.1.3 which, hopefully, improves the compatibility of exhale generated .m4a files a bit more. See this commit. Please let me know as soon as possible whether there are any compilation or stdin-encoding or playback related issues on any platforms.

Update: To everyone using (or thinking about using) exhale to generate xHE-AAC files for streaming applications: apart from fixing the generation of immediate playout frames (IPFs) once more, this version allows you to specify a program loudness (LUFS) and sample peak (dBFS) level as additional command-line arguments between the existing preset and file arguments. Note that, when doing so, you need to specify both, the LUFS and dBFS value (if you don't have the peak sample value, I guess you can use something like -0.01).

Example: for encoding with SBR at ~48 kbit/s stereo and with the input audio (here, WAVE file inStereo.wav) having loudness level -12.34 LUFS and sample peak level -0.123 dBFS, use
"exhale.exe b -12.34 -0.123 inStereo.wav outStereo.m4a"
or, when using stdin (e.g. via foobar2000) instead of file based encoding,
"exhale.exe b -12.34 -0.123 outStereo.m4a"
On operating systems other than Windows, adjust the spelling of "exhale.exe" accordingly.

This feature allows you to encapsulate proper loudness information even in the IPFs, which is important for streaming applications where the receiver can tune in to the stream at any time (i.e., any IPF) and cannot rely on the MPEG-4 file header. It is also beneficial for offline use cases such as file based encoding for personal archiving purposes, in order for the loudness information in the IPFs to match that in the MPEG-4 header (which always contains the actual audio loudness and peak sample level measured by exhale during encoding). So you need to make sure that the LUFS/dBFS values that you pass to the exhale application math those reported by the application once the encoding is complete.

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

Re: exhale - Open Source USAC encoder

Reply #606 –
The commit 8cdc188b compiles without errors on Linux and macOS (I have tested only for armv7l and arm64).

Re: exhale - Open Source USAC encoder

Reply #608 –
Intel compiles of exhale-v1.1.3-8cdc188b now at Rarewares. (Compiles cleanly with no errors. ;))

Re: exhale - Open Source USAC encoder

Reply #609 –
Compiled and ran well on Slackware Linux:

Code: [Select]
andrew@ilium/mnt/ssd2/luckynight$ exhale b -12.34 -0.123 luckynight.wav outStereo.m4a

  ---------------------------------------------------------------------
 | exhale - ecodis extended high-efficiency and low-complexity encoder |
 |                                                                     |
 | version 1.1.3 (x64, built on Mar  3 2021) - written by C.R.Helmrich |
  ---------------------------------------------------------------------

 Encoding 44-kHz 2-channel 16-bit WAVE to low-complexity xHE-AAC at 48 kbit/s

 Progress: ----------------- Done, actual average incl. SBR data 54.08 kbit/s

 Input statistics:  File loudness -14.94 LUFS,	sample peak level -0.20 dBFS

andrew@ilium/mnt/ssd2/luckynight$

Now if only standard Linux players could come at this.... but I am still excited to see the files being produced with an Open Source application :)

Re: exhale - Open Source USAC encoder

Reply #610 –
Quote from: NetRanger on
exhale v1.1.3-8cdc188b (Stable)
Built on March 01, 2021, GCC 10.2.0

https://gitlab.com/ecodis/exhale

This one was a second faster than Intel compiled one on Ryzen 5 3600, for a song that lasts 10:38. So, for a whole album there would be around 6-7 seconds difference. Not a thing to be concerned by... except if you want to encode your whole collection :)
Error 404; signature server not available.

Re: exhale - Open Source USAC encoder

Reply #611 –
There is one Linux player that already has native support, or at least two. Rhythmbox, assuming your copy of GStreamer was built with libfdkaac support. Or Gnome's generically named music player, I forget its name.

Neither player will support seeking USAC right now, though.

Re: exhale - Open Source USAC encoder

Reply #612 –
@itisljar

Are you running 64-bit?
"Something bothering you, Mister Spock?"

Re: exhale - Open Source USAC encoder

Reply #613 –
Quote from: kode54 on
There is one Linux player that already has native support, or at least two. Rhythmbox, assuming your copy of GStreamer was built with libfdkaac support. Or Gnome's generically named music player, I forget its name.

And now you have jogged my old memory I remember that FFpaly will also play these files back by specifying libfdk_aac as the audio codec on the command line...

Re: exhale - Open Source USAC encoder

Reply #614 –
Quote from: Destroid on
@itisljar
Are you running 64-bit?

Who runs 32 bit in this day and age? (Well, I guess there are some people that HAS TO...)
64 bit OS, 64 bit encoders. Why? Are 32 bit faster?
Error 404; signature server not available.

Re: exhale - Open Source USAC encoder

Reply #615 –
All those players and encoder implementations are violating numerous patents.

Re: exhale - Open Source USAC encoder

Reply #616 –
Not necessarily, if you go back in the discussion you will find that I have paid the license to be able to distribute the compressed files to third parties without problems but nothing prevents you from compiling the software for personal use and evaluating the final compression and decompression performance.

For example, Exhale is distributed in source code form. You must have the software to compile it and in many cases you will have to compile the decoder as well, with the risk of failing. This does not affect the rights of the patent holders.

If you use Linux, Windows or other operating systems without the decoder you will have to compile a program built with libfdk_aac support, as suggested by kode54, and I honestly, I still can't.

In my opinion, buying a software that performs this task is the simplest choice to make, even if there is not a wide choice.

Sometimes even after paying for the software new needs arise, for example I also bought Exhale together with https://www.poikosoft.com/music-converter which only works with Windows, while now I'm using Linux. I can download Exhale and compile it for Linux relatively easily.

The tricky part is being able to hear the compressed files; to achieve the purpose I can use the command line to get libfdk_aac:
Code: [Select]
mkdir ~ / fdk-aac
git clone --depth 1 https://github.com/mstorsjo/fdk-aac.git ~ / fdk-aac \
  && cd ~ / fdk-aac \
  && autoreconf -fiv \
  && ./configure \
  && make -j $ (nproc) \
  && sudo make install

After this step all that remains is to compile ffmpeg with the fdk-aac library so that you can play the files with the command:
Code: [Select]
ffplay -acodec libfdk_aac your_file_name.m4a

In my opinion you have to try, but really, surely afterwards you will enjoy paying those who offer you a solution in exchange for money much more.

I believe that in this place the interests of those who write the software meet with the passion of those who want to use it, no one harms the others and not even the patent holders. Thinking that it is easier to pay only with your time what costs a few dollars is equivalent to giving zero value to your time (which is a non-renewable resource for anyone) and also to your skills.

Re: exhale - Open Source USAC encoder

Reply #617 –
Quote from: mycroft on
All those players and encoder implementations are violating numerous patents.
Maybe they'll start caring when someone actually comes after people with lawsuits.

P.S. It may be worth moving all hosting to France, where there's none of this software patent rubbish.

Re: exhale - Open Source USAC encoder

Reply #619 –
exhale-2d0fa2f1 Linux armv7

This version increases the bitrate needed to encode the human voice. I have add 1 min of Italian speech recorded simultaneously with two different microphones by a professional (with some tics), the Neumann U87 Ai (called U87AI) and sE Electronics X1 T (called sEX1T).

U87AI.wav | U87AI.opus | U87AI.m4a (b) | U87AI.m4a (b)

sEX1T.wav | sEX1T.opus | sEX1T.m4a (b)

Only the sEX1T.m4a file was compressed with Exhale commit 2d0fa2f1. The problem is not the increasing bitrate but the voice quality which cannot be so compromised with option b. Even in modes without SBR it is useful to have the zero option which sacrifices too much quality to contain space but IMHO not the others too. I added Opus at 24kbps (SILK + CELT).

Re: exhale - Open Source USAC encoder

Reply #620 –
exhale v1.1.3-2d0fa2f1 Intel compiles now at Rarewares.

Re: exhale - Open Source USAC encoder

Reply #621 –
Sorry, celona, I don't fully understand your previous post. Are you saying that version 2d0fa... makes voice sound worse than release 1.1.3 in the SBR modes?

Quote from: itisljar on
This one was a second faster than Intel compiled one on Ryzen 5 3600, for a song that lasts 10:38. So, for a whole album there would be around 6-7 seconds difference. Not a thing to be concerned by...
Indeed. It seems that, for noticeable speed-ups, "manual magic SIMD code" from (if memory serves) experts like Saratoga and lvqcl would be required.

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

Re: exhale - Open Source USAC encoder

Reply #622 –
Quote from: C.R.Helmrich on
Sorry, celona, I don't fully understand your previous post. Are you saying that version 2d0fa... makes voice sound worse than release 1.1.3 in the SBR modes?

I apologize, I was unclear, the problem also exists in previous versions, Exhale can be a valid tool to contain space and preserve good quality of music, but it doesn't work as well with low bitrate voice alone (24kbps was a declared goal of the developer). A slightly different strategy is needed to make sense of this encoder which has the advantage of being standardized by ISO at bitrate where it competes with telephony encoders, which unlike xHE-AAC (or USAC) cannot be used with the HTML5 <audio> tag . I will write here later to give you some ideas and some numbers.
 

Re: exhale - Open Source USAC encoder

Reply #623 –
Thanks for the clarification. Please remember that exhale does not implement USAC's speech coding part (ACELP/TCX). To reference myself from the early days of this thread: https://hydrogenaud.io/index.php?topic=118888.msg980837#msg980837
Quote
xHE-AAC's advantage over its ancestors is much more obvious at rates lower than that. Adding the algorithms necessary for such low-rate coding (ACELP, TCX, ...) would roughly triple the amount of source code and, possibly, work-hours (I like to write my source code from scratch and work on exhale in my free-time), and I won't be able to manage that. So I decided to leave the low rates to commercial encoders.

Meanwhile I tested your files myself, and the current version increases the bit-rate by only ~0.3 kbps.

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

Re: exhale - Open Source USAC encoder

Reply #624 –
Linux users may be interested to know that I have reworked my exhale patch against the current git of the audio CD ripper abcde. Tested it and it all works very, very well. Details published here;

abcde: Ripping to AAC...
https://www.andrews-corner.org/abcde/abcde_aac.html#exhale

I am aware that the exhale default options are quite conservative but these are very easily tweaked by an enthusiastic user :)