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

Re: exhale - Open Source USAC encoder

Reply #250
Great work!

Anyone else running into issues compiling this for aarch64 (runs fine on amd64)?
https://pastebin.ubuntu.com/p/mBb3D9ZrRK/

FreeBSD 13-CURRENT, aarch64 (rockpro64) using cmake

Looks like the infamous "char is unsigned on ARM" issue. Maybe, as a simple experiment, try to replace all `char` occurrences  with `int8_t` and see what happens?

That seems to fail on my end but I might be doing something wrong...


Re: exhale - Open Source USAC encoder

Reply #252
So far I haven't done many CVBR mode specific tunings, so I'm quite sure this is not the case. It's just too low of a bit-rate for 44.1 kHz sampling rate, I would say.
Yes, You're right. I should probably just mention that different artifacts are less/more audible at different bitrates and sampling rates. And leave it there.


Re: exhale - Open Source USAC encoder

Reply #254
My bitrate table is updated. Some data are still missing for 1.0.4 final. 1.0.5 RC1 tests are far from completion but include full data for mode 1 to 4 (and 5 to 9 for a smaller group of non-classical samples).

Small change: I'm now using the two classical boxset (55+29=84CD) alone as reference for classical music and not the 91 CD anymore (84 CD+7 extreme bitrate CD).
Small addition: I add the 25 tracks from a popular music Billboard chart in a separate collumn. It's really tiny set of file (92 minutes) but it may give an idea of how perform the encoder with something else than Bach or Beethoven, flute or orchestra…



Code: [Select]
[code]
                                   |               C L A S S I C A L  M U S I C                 ||  NON-CLASSICAL
------------------------------------------------------------------------------------------------||--------------------
    ENCODER & PRESET               |   BITRATE    |               BONUS STEREO      BONUS       ||    BILLBOARD
                                   |   2 BOXSET   |    MONO       LOW BITRATE    HIGH BITRATE   || 2010…2020 hits
                                   |   (84 CD)    |   (3 CD)         (4 CD)        (3 CD)       ||   (25 tracks)
------------------------------------------------------------------------------------------------||--------------------
FLAC CUEtools       -8             |  579.2 kbps  |   467.7 kbps   264.0 kbps   1028.7 kbps     ||   921.3 kbps
------------------------------------------------------------------------------------------------||--------------------
exhale 1.0.3 [24KHz SOX]   mode 1  |   61.8 kbps  |    61.7 kbps    38.3 kbps     72.0 kbps     ||    68.0 kbps
exhale 1.0.4 [32KHz SOX]   mode 1  |   65.3 kbps  |    56.3 kbps    40.5 kbps     86.0 kbps     ||    ---------
exhale 1.0.4 [32KHz SSRC]  mode 1  |   65.2 kbps  |    50.3 kbps    40.3 kbps     85.0 kbps     ||    69.5 kbps
exhale 1.0.5 RC1 [32KSSRC] mode 1  |   64.4 kbps  |    49.3 kbps    38.8 kbps     85.0 kbps     ||    68.6 kbps
exhale 1.0.5 RC1 [44K]     mode 1  |   64.5 kbps  |    49.7 kbps    42.0 kbps     86.7 kbps     ||    68.2 kbps
                                                                                                ||  
exhale 1.0.3  [32 KHz SOX] mode 2  |   81.3 kbps  |    85.7 kbps    54.3 kbps     96.0 kbps     ||    83.5 kbps
exhale 1.0.4  [32 KHzSSRC] mode 2  |   79.9 kbps  |    66.3 kbps    49.0 kbps     97.0 kbps     ||    84.5 kbps
exhale 1.0.4  [44 KHz]     mode 2  |   78.7 kbps  |    65.0 kbps    51.0 kbps    101.7 kbps     ||    82.9 kbps
exhale 1.0.5 RC1 [44 KHz]  mode 2  |   78.5 kbps  |    64.3 kbps    50.0 kbps    101.7 kbps     ||    82.5 kbps
                                                                                                ||  
exhale 1.0.3               mode 3  |  100.5 kbps  |   100.7 kbps    62.8 kbps    115.0 kbps     ||   101.8 kbps
exhale 1.0.4               mode 3  |   98.6 kbps  |    84.7 kbps    61.8 kbps    119.0 kbps     ||   102.3 kbps
exhale 1.0.5 RC1           mode 3  |   98.4 kbps  |    84.3 kbps    60.3 kbps    119.0 kbps     ||   102.0 kbps
                                                                                                ||  
exhale 1.0.3               mode 4  |  112.0 kbps  |   110.0 kbps    67.5 kbps    126.7 kbps     ||   113.5 kbps
exhale 1.0.4               mode 4  |  110.0 kbps  |    92.3 kbps    65.5 kbps    131.0 kbps     ||   113.9 kbps
exhale 1.0.5 RC1           mode 4  |  110.0 kbps  |    92.3 kbps    65.5 kbps    131.0 kbps     ||   113.9 kbps
                                                                                                ||  
exhale 1.0.3               mode 5  |  133.2 kbps  |   123.7 kbps    77.3 kbps    145.3 kbps     ||   130.8 kbps
exhale 1.0.4               mode 5  |  131.9 kbps  |   122.7 kbps    76.3 kbps    144.3 kbps     ||   130.4 kbps
exhale 1.0.5 RC1           mode 5  |        kbps  |         kbps         kbps          kbps     ||   130.4 kbps
                                                                                                ||  
exhale 1.0.3               mode 6  |  145.8 kbps  |   130.7 kbps    82.5 kbps    157.3 kbps     ||   142.6 kbps
exhale 1.0.4               mode 6  |  144.5 kbps  |   130.7 kbps    82.5 kbps    157.3 kbps     ||   142.2 kbps
exhale 1.0.5 RC1           mode 6  |        kbps  |         kbps         kbps          kbps     ||   142.2 kbps

exhale 1.0.3               mode 7  |  162.6 kbps  |   143.3 kbps    89.5 kbps    174.0 kbps     ||   158.8 kbps
exhale 1.0.4               mode 7  |  161.2 kbps  |   143.0 kbps    89.0 kbps    173.3 kbps     ||   158.5 kbps
exhale 1.0.5 RC1           mode 7  |        kbps  |         kbps         kbps          kbps     ||   158.5 kbps

exhale 1.0.3               mode 8  |  179.5 kbps  |   153.3 kbps    97.3 kbps    193.7 kbps     ||   177.7 kbps
exhale 1.0.4               mode 8  |        kbps  |         kbps         kbps          kbps     ||   177.3 kbps
exhale 1.0.5 RC1           mode 8  |        kbps  |         kbps         kbps          kbps     ||   177.3 kbps

exhale 1.0.3               mode 9  |  193.0 kbps  |   163.0 kbps   102.5 kbps    207.7 kbps     ||   191.0 kbps
exhale 1.0.4               mode 9  |        kbps  |         kbps         kbps          kbps     ||   190.5 kbps
exhale 1.0.5 RC1           mode 9  |        kbps  |         kbps         kbps          kbps     ||   190.5 kbps


• mode 1 and 2 are ~1 kbps smaller with 1.0.5 RC1 compared to 1.0.4 “E”. Difference is even smaller with mode 3. From mode 4 to mode 9, bitrate is or seems identical (based on "Billboard" group).
• the small "billboard" group (non-classical) shows higher bitrate for mode 1 to 4 compared to the larger classical music group (on average, + 4 kbps).
• high bitrate stereo discs (harpsichord) are twice bigger than low bitrate stereo discs (quiet piano), which is a satisfying ratio for VBR/CVBR.

Re: exhale - Open Source USAC encoder

Reply #255
Try this patch.
Thanks. I took this patch, added some more "char" related fixes, and included everything in my most recent commit to the exhale repository. Does that work for you and diizzy?
My bitrate table is updated. Some data are still missing for 1.0.4 final. 1.0.5 RC1 tests are far from completion but include full data for mode 1 to 4 (and 5 to 9 for a smaller group of non-classical samples).
Wonderful, thanks! Looks good to me.

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

Re: exhale - Open Source USAC encoder

Reply #256
Try this patch.
Thanks. I took this patch, added some more "char" related fixes, and included everything in my most recent commit to the exhale repository. Does that work for you and diizzy?
My bitrate table is updated. Some data are still missing for 1.0.4 final. 1.0.5 RC1 tests are far from completion but include full data for mode 1 to 4 (and 5 to 9 for a smaller group of non-classical samples).
Wonderful, thanks! Looks good to me.

Chris

Confirmed working, many thanks!

If it's of any interest, about 2.7x encoding speed using preset 5 on my RockPro64 board (44.1kHz WAV(E) file as input).

Re: exhale - Open Source USAC encoder

Reply #257
If it's of any interest, about 2.7x encoding speed using preset 5 on my RockPro64 board (44.1kHz WAV(E) file as input).
Interesting, thanks for the info! Still faster than real-time, that's nice to see. And ARM support may become more important in the future, since Apple is planning to switch from Intel to ARM based processors in its desktop computers.

By the way, is anyone compiling exhale on MacOS (clang)? Does it still work?

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

Re: exhale - Open Source USAC encoder

Reply #258
Yes, it still works.

 exhale@12bb5715.zip  (104.78 KB)




MOD edit: change attachment tag (attach > attachurl)

Re: exhale - Open Source USAC encoder

Reply #259
Hello,

What I haven't yet been able to take a look at is the issue reported by AiZ here. I suspect that the WAVE files which exhale doesn't like are Broadcast/Extensible-WAV format files, which is a format exhale currently doesn't support. Can anyone confirm this?

You're right : after a bit of Googling and extracting information with MediaInfo, all problematic files have the '00000001-0000-0010-8000-00AA00389B71' Codec ID, sign of Extensible Wave-Format.

    AiZ


Re: exhale - Open Source USAC encoder

Reply #261
Current Release Candidate, I've designated it RC3 just to differentiate it, not sure it's the correct version. ;)

www.rarewares.org/files/aac/exhaleApp-v.1.0.5rc3-74518cae_x64.zip

www.rarewares.org/files/aac/exhaleApp-v.1.0.5rc3-74518cae_x86.zip

Re: exhale - Open Source USAC encoder

Reply #262
Counting all commits since the first release candidate above, RC3 is correct. For all those using the exhale application stand-alone or through foobar2000: this is likely to become the final version next week, and there were several bugfixes and compatibility improvements since version 1.0.4, so reencoding of any music collections is encouraged.

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

Re: exhale - Open Source USAC encoder

Reply #263
Interesting, thanks for the info! Still faster than real-time, that's nice to see. And ARM support may become more important in the future, since Apple is planning to switch from Intel to ARM based processors in its desktop computers.

Yesterday Apple have suggested to the developers to encode everything in xHE-AAC using previous encoders only for interoperability. This means that afconvert will no longer be limited to only playing MPEG-D USAC.

https://developer.apple.com/videos/play/wwdc2020/10636/

Re: exhale - Open Source USAC encoder

Reply #264
Hi, I have been trying out exhale, and so far so good, but to make things easier I noticed exhale is apparently capable of taking input from stdin, so I had assumed I should be able to pipe to exhale from ffmpeg instead of having to convert everything to wav first?  Anyway below is the command (one of the ones I have tried anyway) I am trying to use:
Code: [Select]
ffmpeg.exe -i input.??? -f wav - | exhale.exe 5  "output.m4a"
Which isn't working, so my question is, is piping from ffmpeg possible or should I give up on this method?
Try to add:
Code: [Select]
-map_metadata -1 -bitexact
parameters to ffmpeg.
I just realized that exhale had a bug when reading WAVE audio from stdin that contains metadata (which exhale must skip but didn't do so properly). Please try again with the latest Git commit, it should now work even without specifying -map_metadata or -bitexact anymore.

Yesterday Apple have suggested to the developers to encode everything in xHE-AAC using previous encoders only for interoperability. This means that afconvert will no longer be limited to only playing MPEG-D USAC.

https://developer.apple.com/videos/play/wwdc2020/10636/
Interesting! Is this afconvert version already available?

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

Re: exhale - Open Source USAC encoder

Reply #265
@celona Even 10.15 already supported USAC in both MPEG-4 and CAFF containers. As does iOS/iPadOS 13.


Re: exhale - Open Source USAC encoder

Reply #267
I'm following this thread from beginning with great interest. :)
I made few encodes from flac with foobar2000 just to see how it goes...
I don't know is it already mentioned somewhere but one thing I noticed when scanning for ReplayGain with foobar2000, that track peak value on converted files is never above 0.98 which is a good thing (I think). Usually other lossy like vorbis/opus/mp3 end up with peak values above 1.00.
lame --abr 288 -f --lowpass 17 (+ mp3gain@92 dB)

 

Re: exhale - Open Source USAC encoder

Reply #269
Interesting! Is this afconvert version already available?
The afconvert version for Apple SoC is only available for developers who pay for the transition kit, the 64-bit version for Intel is downloadable from registered developers who pay about $ 100 a year.

In fact, afconvert has not changed, it could be the same as openDarwin, it only allows you to use codecs supported by macOS.

From July anyone can download beta versions of Apple software for free; also in other videos they suggested the use of xHE-AAC for streaming in fMP4.

https://developer.apple.com/videos/play/wwdc2020/10158/

Re: exhale - Open Source USAC encoder

Reply #270
I just like to submit an old issue that still occurs with 1.0.5 RC4 but with some improvements: corrupted or incorrect files when encoded with foobar2000 with resampling on the fly. There are some progress with 1.0.5 RC4 but problem is not fully solved.

The issue usually occurs with long files (full tracks/album) and I had hard times to find short samples sharing the same issues. But I managed to isolate three short samples (30 seconds) among hundreds for which exhale used to struggle when they have to be encoded and resampled in the same process with foobar2000 1.54. But with 1.0.5 RC4 issues are now gone with these 3 short samples (1.0.4 and 1.0.3 have this issue). Problem solved? Unfortunately not. If I encode larger albums with 1.0.5 RC4 with resampling on the fly I still get many errors:



Files marked as M4A are corrupted ; AAC/USAC are good. I get these results with 1.0.5 RC4, SSRC resampling 32000 Hz with foobar2000 1.54.

____
Below I joined the three FLAC samples which may help to understand the issue with larger files.
Odd things: I duplicate these three samples many times with explorer and encoded all copies with exhale 1.0.4 and foobar2000/SSRC and I managed to get few valid files among a lot of corruption. In other words, bit-identical files are sometime OK and often WRONG when encoded in the same batch with foobar2000 :


(on this picture, two files are file, all others identical copies are M4A and unreadable).

I also uploaded two encoded files from this batch (1.0.4 mode 1): one corrupted and one which is playable. Both should be identical because source files are also identical. Maybe these files may help to understand from where the differences and the issue come from.

As said, the problem is solved with 1.0.5 for short samples but still occurs with longer ones which are not so easy to share in public.

I submitted it because I tried today to encode a ISO-SACD file (DSD set to PCM 88200Hz for playback/decoding) with exhale mode 9 and while encoding seems to work the resulted files are sometimes corrupted.

N.B. Curious fact I just noticed few seconds ago: only the first track of SACD is corrupted (tested with three different SACD: issue occurs with 2 of them). And it's maybe not a coincidence, all three short samples submitted here are also the very beginning of the CD (seconds 0 to 30 from the first track). Any idea? Could the very beginning of a disc have an impact?


Re: exhale - Open Source USAC encoder

Reply #272
From July anyone can download beta versions of Apple software for free
Thanks for the information, let's see if afconvert will be freely accessible then as well, at least for a short time.

when scanning for ReplayGain with foobar2000, that track peak value on converted files is never above 0.98 which is a good thing (I think). Usually other lossy like vorbis/opus/mp3 end up with peak values above 1.00.
This is a feature of the xHE-AAC decoding standard and kode54's packet decoder in particular, it applies a limiter to the decoded waveforms at -0.1 dBFS.

Thanks for the report, guruboolez! Before I change exhale in a rush at the last minute before the upcoming 1.0.5 release (i just fixed the last urgent issue I'm currently aware of, a minor WAVE metadata related read-in hickup here), let's try a potential fix privately first. I'll PM you.

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

Re: exhale - Open Source USAC encoder

Reply #273
From July anyone can download beta versions of Apple software for free
Thanks for the information, let's see if afconvert will be freely accessible then as well, at least for a short time.
I don't know about whatever public beta they have planned for July, but the first Developer Beta I have now, refuses to encode xHE-AAC with afconvert. It is not a problem with the source material. It just outright refuses to accept the default settings, and I don't see any documentation of what bitrates or settings they support.

when scanning for ReplayGain with foobar2000, that track peak value on converted files is never above 0.98 which is a good thing (I think). Usually other lossy like vorbis/opus/mp3 end up with peak values above 1.00.
This is a feature of the xHE-AAC decoding standard and kode54's packet decoder in particular, it applies a limiter to the decoded waveforms at -0.1 dBFS.
Not just a feature of the encoding standard. The decoder I use literally can't output over ±1.0. Android's decoder library outputs 16 bit integer PCM. It can be configured at compile time to output 32 bit integer PCM, also with the same range limit, at the expense of also doing all the fixed point math in 32/64 bit precision instead of just 32 bit.

The only way this will ever change is if there are system codecs which don't suck.

foobar2000 for Mac has also recently added USAC support, using system codecs, so that functionality requires Catalina or newer. Apple's system codecs don't suck. Microsoft's kind of do, and they also don't support USAC yet, with no announced plans for support that I've seen anywhere.

We're limited to either system codecs or FDK-AAC. System codecs *may* support unclipped output, except on Android, and FDK-AAC anywhere else does not.

Re: exhale - Open Source USAC encoder

Reply #274
Not just a feature of the encoding standard. The decoder I use literally can't output over ±1.0. Android's decoder library outputs 16 bit integer PCM. It can be configured at compile time to output 32 bit integer PCM, also with the same range limit, at the expense of also doing all the fixed point math in 32/64 bit precision instead of just 32 bit.
Thanks for the clarification! Would it be possible for you to, without much extra work, share such a 32-bit version of your packet decoder for me to test? exhale theoretically can encode dynamic ranges of more than 120 dB, but due to the rounding to 16 bits during decoding, it's hard for me to figure out if things work properly in very quiet signal passages during encoding. The increase in the required decoding resources wouldn't be an issue for me, your packet decoder already runs at almost 100x realtime per thread.
Quote
Apple's system codecs don't suck. Microsoft's kind of do, and they also don't support USAC yet, with no announced plans for support that I've seen anywhere.
This is an interesting point. Microsoft added FLAC decoding support a few years ago, so maybe they would be open to support xHE-AAC decoding, especially now that Apple and Google support it. There is a Feedback Hub in Windows 10 which allows to search for, and add new, feature requests to "improve the Windows experience". Maybe someone has already requested it there or could do so if not?

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