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

Re: exhale - Open Source USAC encoder

Reply #400 –
slower than what?

Re: exhale - Open Source USAC encoder

Reply #401 –
Slower than all the other modes.

And I made a mistake. It's mode 5 at 128kbps that's slower.

On the new 1.0.7 RC1, mode 0 is clearly faster than all the modes (x86 binary).
"Something bothering you, Mister Spock?"

Re: exhale - Open Source USAC encoder

Reply #402 –
I have come to completely wrong conclusions in the past because I did a lot of testing and have confused the files produced by myself. The forum terms of service in point 8 state that graphs, non-blind listening tests, waveform difference comparisons, and so on, are not acceptable. Or at least that's what I understand.

Wanting to avoid myself further ugly figures, I thought of writing directly to the developer, although I have enormous doubts about the graphics provided. I hope not to irritate the administrators if I use this scam to show a software bug, but I consider your opinions very important and otherwise I would not be a regular reader of this forum.

I ask forgiveness in advance, thank you.

https://gitlab.com/ecodis/exhale/-/issues/14

Re: exhale - Open Source USAC encoder

Reply #403 –
Your graphs show that exhale's resampler is different from the other resampler you compared it against, but that's all. They don't show that one is better than the other by any metric.

If you want to compare the technical merits of resamplers, you need graphs like these.

If you want to know which one sounds better, you need blind listening tests.
 

Re: exhale - Open Source USAC encoder

Reply #404 –
Final commit for this release, I was informed of an inaccuracy in exhale's loudness estimation and corrected that, at least for 44.1 and 48 kHz sampling rate it should now be quite accurate. If you manage to compile this release without errors, please call it version 1.0.7. I'll tag this later, after having run it through my own test suite. Btw, the audio quality hasn't changed since the last release candidate, only the loudness value inside the file header might have.

Quote from: Destroid on
It's mode 5 at 128kbps that's slower.
On the new 1.0.7 RC1, mode 0 is clearly faster than all the modes (x86 binary).
Two reasons for this. First, at the lower CVBR modes where a sampling rate of 32 kHz or less is used, the encoder needs to process fewer samples (i.e., frames) per second. Second, the more frequency coefficients are quantized to zero, which of course happens a lot at mode 0, the faster exhale's entropy coder can run. Regarding mode 5 being the slowest mode: I configured the higher modes such that they are roughly as fast/slow as modes 4 or 5, but that configuration is quite coarse. Do you have a detailed table of speeds per CVBR mode and sampling rate by any chance?

Quote from: Octocontrabass on
Your graphs show that exhale's resampler is different from the other resampler you compared it against, but that's all.
What I believe I can read from celona's screenshots (the waveform display in the background) is that his resampler has a slightly lower (possibly unnecessarily low) cutoff frequency. But to be sure, Christian, can you share your manually 32-kHz downsampled sweep WAV file, i.e., the one you used to obtain the Sweep20-20_20sec_-6dB_32k.wav.png screenshot in the Git issue?

A note on the loudness metadata: xHE-AAC has built-in loudness and sample peak value metadata according to ISO/IEC 23003-4 (DRC standard) similar to ReplayGain, so it should not be necessary to write ReplayGain tags to xHE-AAC files (with that file format, doing so is considered obsolete). Still, exhale cannot write album loudness information since it doesn't know about albums, only files (where each file is considered an "audio program"). If there is interest in extending the xHE-AAC file headers written by exhale with ISO/IEC 23003-4 album loudness values (and, possibly, album sample peak values), I'm open to disuss this, e.g. with Peter and Christopher in the context of foobar2000.

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

Re: exhale - Open Source USAC encoder

Reply #405 –
Intel compiles of exhale-v.1.0.7-54a7bcd7 now available at Rarewares. :)

Re: exhale - Open Source USAC encoder

Reply #406 –
Quote from: C.R.Helmrich on
Christian, can you share your manually 32-kHz downsampled sweep WAV file, i.e., the one you used to obtain the Sweep20-20_20sec_-6dB_32k.wav.png screenshot in the Git issue?


Obtained with afconvert --src-complexity norm, I can supply also the best quality version (bats) but my purpose was not to evaluate the quality of the encoder, but only to evaluate whether to use internal SRC or other.


I also add the compressed version obtained, of only 31,688 bytes.

Re: exhale - Open Source USAC encoder

Reply #407 –
Quote from: celona on
... my purpose was not to evaluate the quality of the encoder, but only to evaluate whether to use internal SRC or other.
Well, that I can easily answer: if your original source material is in 48 kHz, use exhale's built-in resampler ;) Seriously, don't worry about the resampling if you don't have to. exhale's 48-to-32-kHz resampler was specifically designed to run fast, have a high cutoff frequency (it starts rolling off around 15 kHz IIRC while your afconvert version starts rolling off already at 14 kHz), avoid unnecessary stop-band and near-Nyquist aliasing rejection which will be masked by the low-rate compression errors, and always result in the maximum bit-depth entering the encoding process (around 24 bits per sample). Oh, and you would either have to use some on-the-fly resampling with a stdout-to-stdin cascade or you'd need to create temporary 32-kHz resampled files which you then feed into exhale.

Lots of things I wouldn't want to worry about if I were you :)

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

Re: exhale - Open Source USAC encoder

Reply #408 –
Quote from: C.R.Helmrich on
Do you have a detailed table of speeds per CVBR mode and sampling rate by any chance?

I can PM my entire benchmark history going back to 1.0.2.

If my memory serves, my machine encodes most modes with 44 khz material at 10.5x to 11, and even mode 1 is close to the same speed despite its resampled by SoX at 24khz. Mode 5 encodes slower at about 9.5x. Mode 0 (resampled by SoX to 24khz) in 1.0.7 RC1 encodes faster at over 13x. These test were with 86 binaries. (Thanks again, john33 :)
"Something bothering you, Mister Spock?"

Re: exhale - Open Source USAC encoder

Reply #409 –
OK, I've encoded some music with exhale 1.07 and tested it on my Samsung A50, with latest updates, It runs Android 10.
PowerAmp won't play these files, which is expected as its decoders are based on ffmpeg. Samsung Music plays these files, but I can't jump inside some position in song, just says it is not playable (and it was playing that exact file!) and skips to next song.
Didn't test any other player, because I don't really know which one should work - does anyone has suggestions?
TAPE LOADING ERROR

Re: exhale - Open Source USAC encoder

Reply #410 –
whats about playing this files on PC ?

Re: exhale - Open Source USAC encoder

Reply #411 –
Everything as expected. playing in foobar2000, with that extra decoder installed. can play, can jump around the song.
TAPE LOADING ERROR

Re: exhale - Open Source USAC encoder

Reply #412 –
Quote from: Destroid on
If my memory serves, my machine encodes most modes with 44 khz material at 10.5x to 11, and even mode 1 is close to the same speed despite its resampled by SoX at 24khz. Mode 5 encodes slower at about 9.5x. Mode 0 (resampled by SoX to 24khz) in 1.0.7 RC1 encodes faster at over 13x.
Thanks for the benchmarking, Destroid! I reconfigured CVBR mode 0 to do slightly "more exhaustive" parameter searching during the quantization step, so it should run a bit slower now. At the same time, I also shaved off around 1 additional kbit/s for 32-kHz encoding at mode 0 (with the previous version, the bit-rates tended to be a bit higher than the 48 kbit/s target rate).

The new version is still version 1.0.7 since the changes are so minor.

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

Re: exhale - Open Source USAC encoder

Reply #413 –
New compiles on the Rarewares-aac encoders page. :)

Re: exhale - Open Source USAC encoder

Reply #414 –
This might be a little off-topic, but between MPEG-H, Dolby AC-4 and xHE-AAC which codec do you guys think is more efficient in theory?
There doesn't seem to be publicly available encoders for MPEG-H and Dolby AC-4 to compare with.

Re: exhale - Open Source USAC encoder

Reply #415 –
xHE-AAC and Dolby AC4 have similar  tools. I would say xHE-AAC has a  slight edge.

MPEG-H (3DA) format is considerably more efficient that xHE-AAC as it replaces SBR by IGF (much better BW extension)  and introduction of  better and similar  [semi]-parametric tools  like stereo filling etc. 

 As a rule of thumb, MPEG-H provides ~16 kbps  bitrate reduction comparing to xHE-AAC/USAC. But there is no encoder/decoder around afaik.  Plus xHE-AAC is still struggling to get  decoding support  in ffmpeg, that's when in my opinion  it will be usable.



Re: exhale - Open Source USAC encoder

Reply #416 –
How to play it on linux? I've compiled it from the source and moved bin to /usr/bin, made it executable, tested, it works; but I am struggling to find player to play it. Have you found something to play it in Linux? I am using Mint... I think it's 20.04 :)
TAPE LOADING ERROR

Re: exhale - Open Source USAC encoder

Reply #417 –
For players like strawberry, try installing gst-plugins-bad or whatever the equivalent of it is in linux mint. I'm guessing libgstreamer-plugins-bad?

Re: exhale - Open Source USAC encoder

Reply #421 –
Quote from: itisljar on
How to play it on linux? I've compiled it from the source and moved bin to /usr/bin, made it executable, tested, it works; but I am struggling to find player to play it. Have you found something to play it in Linux?

I think it has been mentioned elsewhere in this thread but if you copy of FFmpeg has been compiled against fdkaac the following will work from the command line:

Code: [Select]
ffplay -hide_banner -loglevel 0 -autoexit -codec:a libfdk_aac test.m4a

Perhaps a bit cumbersome but it works well enough...

Re: exhale - Open Source USAC encoder

Reply #422 –
Just did a quick number crunching experiment where I tried to fit a simple function through the mean opinion score (MOS) values recently posted for exhale on this forum, in order to estimate the stereo audio quality exhale would roughly produce on mixed-genre music for an experienced listener (like those on HA). I came up with the function 2.09 * log10(target bit-rate in kbit/s), see the attached graphic. For comparison I added, with the corresponding 95% confidence intervals, the MOS of

  • Guruboolez's 64-kbit/s "contemporary" test archived here (CVBR mode 1 @ 32 kHz, actual bit-rate on his test set 69 kbit/s)
  • Kamedo2's 96 and 128-kbit/s multi-bit-rate test archived here (CVBR modes 3 and 5, actual bit-rates 99.1 and 128.7 kbit/s)
  • IgorC's 192-kbit/s high-rate test archived here (CVBR mode 9, actual bit-rate unknown to me - Igor, is it exactly 192 kbit/s?)



Interestingly, the average predicted quality at CVBR mode 9 is lower than what Igor reported. Also, all confidence intervals cross the curve, which means that it is a quite accurate approximation, and the curve crosses the 4.0 quality score (perceptible, but not annoying quality degradations) at 82 kbit/s, which is almost exactly the bit-rate you get with CVBR mode 2. So that mode seems to be quite a good choice for casual listening.

And, finally, the MOS predicted for the new CVBR mode 0 @ 32 kHz, averaging at roughly 50 kbit/s, is 3.55. I'm curious if that's reasonable ;)

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

Re: exhale - Open Source USAC encoder

Reply #423 –
Quote from: C.R.Helmrich on
  • IgorC's 192-kbit/s high-rate test archived here (CVBR mode 9, actual bit-rate unknown to me - Igor, is it exactly 192 kbit/s?)
196 kbps  on my bitrate calibration set of multi genre music.

Quote from: C.R.Helmrich on
And, finally, the MOS predicted for the new CVBR mode 0 @ 32 kHz, averaging at roughly 50 kbit/s, is 3.55. I'm curious if that's reasonable ;)
Yes, it's very reasonable. According to this test xHE-AAC outperformed the best HE-AAC encoders at 48 kbps .
And HE-AAC@48 kbps has  landed at ~ 3.3-3.6 range in previous public tests
So, yes, it's in line with other tests.

Re: exhale - Open Source USAC encoder

Reply #424 –
I'm back in the thread.

Exhale 1.07 at mode 0 (48 kbps at 32000 Hz) was tested against OPUS and HE-AAC, and it's really competitive!



Code: [Select]
FRIEDMAN version 1.24 (Jan 17, 2002) http://ff123.net/
Blocked ANOVA analysis

Number of listeners: 60
Critical significance:  0.05
Significance of data: 0.00E+000 (highly significant)
---------------------------------------------------------------
ANOVA Table for Randomized Block Designs Using Ratings

Source of         Degrees     Sum of    Mean
variation         of Freedom  squares   Square    F      p

Total              299         455.02
Testers (blocks)    59          57.64
Codecs eval'd        4         299.02   74.75   179.36  0.00E+000
Error              236          98.36    0.42
---------------------------------------------------------------
Fisher's protected LSD for ANOVA:   0.232

Means:

HIGH     USAC     OPUS     HE-AAC   LOW      
  4.74     3.08     3.07     2.69     1.64   

---------------------------- p-value Matrix ---------------------------

         USAC     OPUS     HE-AAC   LOW      
HIGH     0.000*   0.000*   0.000*   0.000*   
USAC              0.910    0.001*   0.000*   
OPUS                       0.001*   0.000*   
HE-AAC                              0.000*   
-----------------------------------------------------------------------

HIGH is better than USAC, OPUS, HE-AAC, LOW
USAC is better than HE-AAC, LOW
OPUS is better than HE-AAC, LOW
HE-AAC is better than LOW
https://hydrogenaud.io/index.php?topic=120081.msg989570;topicseen#new
Wavpack Hybrid -c4hx6