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

Re: exhale - Open Source USAC encoder

Reply #1225 –
Quote from: birdie on
I guess it can beat or at least match 128kbps MP3 at 64kbps.
Your guess is wrong. 

Kamedo2 test https://hydrogenaud.io/index.php/topic,120936.0.html
Guruboolez test https://hydrogenaud.io/index.php/topic,119333.0.html

70 kbps https://listening-test.coresv.net/img2/20aac-ha-enx2.png
64-70 kbps https://zupimages.net/up/20/23/tgnw.png



Re: exhale - Open Source USAC encoder

Reply #1226 –
Quote from: btc on
Your guess is wrong. 

Kamedo2 test https://hydrogenaud.io/index.php/topic,120936.0.html
Guruboolez test https://hydrogenaud.io/index.php/topic,119333.0.html

70 kbps https://listening-test.coresv.net/img2/20aac-ha-enx2.png
64-70 kbps https://zupimages.net/up/20/23/tgnw.png

From the topic you've mentioned, https://hydrogenaud.io/index.php/topic,119333.0.html

Quote from: guruboolez on


Looks like USAC/exhale at 69kbps beats LAME at 131kbps.

Re: exhale - Open Source USAC encoder

Reply #1227 –
@birdie
I take my words back. You're right. Guruboolez has tested two sets of samples.
  • Classic. With all respect to classical music lovers, classic music isn't representative anymore for development of audio codecs.  https://rateyourmusic.com/genre/classical-music/
    Classic music is not even in TOP 10 music genres. 
  • Modern Music. it's more representative.
    Exhale has Opus as competitor  which is better supported and has great quality.
    Guru's test at 64k



Re: exhale - Open Source USAC encoder

Reply #1228 –
Exhale has reached good quality, but is version 1.2.1 the definitive version since it was released in 2023 and ffmpeg usac decoder can already decode sbr correctly?



Moderator: clean up misposts and quoting errors

Re: exhale - Open Source USAC encoder

Reply #1229 –
Quote from: btc on
With all respect to classical music lovers, classic music isn't representative anymore for development of audio codecs.

With all respect to your opinion, I'm sure that classical listeners would not want to listen music in any of the compressed formats you promote; they might be fine for modern music, and only as long as their ears are not forced to listen to it.

I would like to point out that you should not look at how many albums are released, but how many are sold, and there you would realize that compressing your music is in the interest of those who buy it uncompressed. And classical sells, for the others there is Spotify and the idea that every pleasure can be ruined to save a few cents.

If you then want to look at sales over time you will realize that the music market no longer exists and despite inflation and price increases the turnover of years gone by remains a dream.

Re: exhale - Open Source USAC encoder

Reply #1230 –
Correct me if I'm wrong, but I thought that the mention of genres in audio compression topics/tests, is used as a sort of disposition to the user regarding specific challenges each genre is known to put upon the codec. For example long transients, content that are prone to cause pre-echo, distortion etc. It has little to nothing to do with the genre as genre per se. You could argue that modern music, especially pop and it's countles subgenres is an amalgamation of all genres, so Classical IS and will always be relevant on such topic.

Re: exhale - Open Source USAC encoder

Reply #1231 –
btc wrote "isn't representative anymore for development of audio codecs".
That is not to say that it is irrelevant for applying them, no need to resort to straw men.

As for "audio codecs" I assume there is a big difference between low-bitrate stereo codecs and whatever is going to be used for high channel count "ambisonics" and the like.

Re: exhale - Open Source USAC encoder

Reply #1232 –
I don't think classical music has ever received special attention in the development of audio codecs, at least not in the past 25 years. In the 90s, the share of classical music in sales had already dropped to around 5% (compared to 15% when the Compact Disc was introduced). Today, it has likely stabilized at 2 or 3% of sales. Given that compression formats are general-purpose, it seems obvious that classical music wouldn't be a priority in software development. However, this doesn't prevent us from examining the performance of these general-purpose codecs on any type of music (including, for example, films or audiobooks).

The only reason we sometimes see differentiated tests between classical music and 'other' music is due to the musical tastes of the tester—in this case, myself. Since I primarily listen to classical music and have developed ABX testing skills over the years, you will find tests on this forum fueled by the music I listen to and enjoy. I initially conducted these tests for myself and shared this (admittedly incomplete) knowledge with the community.
When Exhale appeared 4 or 5 years ago, which rekindled my interest in lossy encoding, it seemed more useful to broaden the range of tested samples to other musical genres so that Christian R. Helmrich could ensure the progress of his encoder was as comprehensive as possible.


Regarding classical music, it is important to note some objective particularities that have nothing to do with Mr. Guruboolez's subjectivity and taste. Taken as a whole, classical music differs from most contemporary recordings by being more compressible with lossless formats (around 40% compared to 55-70% with other genres—the difference is huge). It also stands out, and I think this is related, by having a significantly lower sound volume and a wider dynamic range. The concept of the Loudness War is basically irrelevant in the world of classical music. You can find compelling elements in my bitrate table¹, which presents bitrate as well as calculations of sound volume and dynamics according to several algorithms for 400 recordings (second tab).

Regarding lossy formats, classical music can also behave differently from most other musical genres, which can impact the relevance of a test. For example, OPUS tends to increase the bitrate compared to louder music; others (like LAME MP3) will use fewer binary data in VBR. The tester might adjust the settings consequently. In terms of quality, tests show that there can be significant quality differences between a group of samples from classical music and a group of samples from more contemporary music with generally heavy mastering.

¹Link to the bitrate table :
https://docs.google.com/spreadsheets/d/e/2PACX-1vTGboXIj0Ox9qUL9_wmjIGso2RwCSIMVAqFbirnmy-T3xGVbBFfJ8Hc2bTRqDx2zCbnyQdw3Nk3QQE4/pubhtml

Wavpack Hybrid -c4hx6

Re: exhale - Open Source USAC encoder

Reply #1233 –
In a wider perspective, there has of course been a focus on particular problematic signal types. For classical music, the harpsichord typically stands out requiring higher bitrate for lossless compression.
Does "higher lossless bitrate" (i.e. higher information content) translate to higher bitrate required for (satisfactory quality) lossy compression? Not outright - noise sounds like noise.

Re: exhale - Open Source USAC encoder

Reply #1234 –
Quote from: Porcus on
Does "higher lossless bitrate" (i.e. higher information content) translate to higher bitrate required for (satisfactory quality) lossy compression? Not outright - noise sounds like noise.
Yes but then again not every noise is importantly audible, it could be masked, and noise "A" may not sound like noise "B".
What I mean is when you reach a point that the lossy format has to somehow make some sort of sacrifice for whatever reason, there are better choices than others, and each genre kind of introduces a different set of challenges. It's a really tough job to find a sort of "one size fits all" solution to these challenges but if you exclude out of the equation a genre and it's set of those challenges, it will look like you have to deal with less trouble or be able to fine tune other stuff but instead you are just letting the issues manifest elsewhere since none of these issues are exclusive to this genre.

I like your harpsichord example. You could argue that not alot of people may consume harpsichord content in their media, but it's intricacies are not exclusive to harpsichord! So if somebody would say that harpsichord is sort of irrelevant on tests, and dismiss any type of fine tuning, this will affect other content too.

To summarize what I mean. Since you are building a general use audio format that aims to be content agnostic, you can't claim that this genre or this type of audio is not represenative of what should be taken into consideration in tests or fine tuning. The only case that this could be said is for audio codecs that rely on ML/AI since their datasets are fixed depending on the audio that's been trained on and anything else most probably will would bad.

I hope I'm not viewing this whole thing wrong.

Re: exhale - Open Source USAC encoder

Reply #1235 –
Quote from: enry2k on
Exhale has reached good quality, but is version 1.2.1 the definitive version since it was released in 2023 and ffmpeg usac decoder can already decode sbr correctly?
exhale 1.2.1 will not be the last version, but 1.2.2 most likely will be. I'm planning to release that final version around Christmas.

For those not interested in exhale bitrates higher than ~200 kbps, you can stop reading here. For all others, there's some news.

While working on a small hickup related to SBR preset f (issue #33 for fellow developers), I decided this week to give higher-rate USAC presets a try. First because I found the idea of an archival quality exhale preset compelling for personal use, second because I've seen some threads about new time-domain codecs on HA lately, with claims of "high quality", "full bandwidth", ... whatever. I'm strongly convinced that such codecs are, by design, fundamentally inferior to transform codecs like USAC (though they might be faster, but does that really matter nowadays?).

Anyway, the newest exhale source revision (commit 49517c4d), apart from fixing the preset-f issue and increasing the coding efficiency slightly, includes code which, when activated, allows exhale to encode with up to ~300 kbps (stereo) and up to full CD/broadcast audio bandwidth (24 kHz). To activate this tuning,

change #define SFB_QUANT_PERCEPT_OPT from 1 to 0 in file lib/quantization.h before compiling.

This tuning doesn't make much sense with SBR presets a - g, but with the non-SBR presets, especially 8 and 9, I get nice results.

So, if you're interested in this tuning, please report any compilation errors, audio glitches with these two presets, very high or low rates on specific samples, or anything else which appears fishy. And if someone could provide (or link to) a respective exhale executable compiled for others to do the tests, that would be appreciated as well.

Thanks!

My analysis results for stereo, presets > 4 and different sampling rates:

- for 44.1 kHz sampling rate: avg bitrate = preset * 32 kbps
- for >44 kHz sampling rate: avg rate proportionally higher
- for 32.0 kHz sampling rate: 16 kbps less than for 44.1 kHz

Developer note (mainly for personal reference, in case somebody asks):

- to get decoded waveforms identical to those created by
  exhale 1.2.1, set #define SFB_QUANT_PERCEPT_OPT to 2.

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

Re: exhale - Open Source USAC encoder

Reply #1237 –
Also,

Just encoded one file to check, foobar2000 plays it flawlessly. But with ffplay (ffmpeg) downloaded from https://www.gyan.dev/ffmpeg/builds/:
  • 7.1 doesn't cope with the file, lots of logs displayed on console.
  • 7.1.1 is OK-ish, with some audible glitches, see some console output below.

Code: [Select]
[...]
[aac @ 0000025434729a80] Scalefactor (-6) out of range.
[aac @ 0000025434729a80] Scalefactor (257) out of range.
[aac @ 0000025434729a80] Number of scalefactor bands in group (62) exceeds limit (49).
[aac @ 0000025434729a80] Scalefactor (-1) out of range.
[aac @ 0000025434729a80] Number of scalefactor bands in group (55) exceeds limit (49).
[aac @ 0000025434729a80] Scalefactor (263) out of range.
[aac @ 0000025434729a80] Scalefactor (258) out of range.
[aac @ 0000025434729a80] Scalefactor (-16) out of range.
[aac @ 0000025434729a80] Number of scalefactor bands in group (60) exceeds limit (49).
[aac @ 0000025434729a80] Number of scalefactor bands in group (54) exceeds limit (49).
[aac @ 0000025434729a80] Scalefactor (-1) out of range.
[aac @ 0000025434729a80] Scalefactor (-1) out of range.
[aac @ 0000025434729a80] Scalefactor (-1) out of range.
[aac @ 0000025434729a80] Number of scalefactor bands in group (56) exceeds limit (49).
[aac @ 0000025434729a80] Scalefactor (264) out of range.
[aac @ 0000025434729a80] Number of scalefactor bands in group (53) exceeds limit (49).
[aac @ 0000025434729a80] Number of scalefactor bands in group (61) exceeds limit (49).
[aac @ 0000025434729a80] Number of scalefactor bands in group (15) exceeds limit (14).
[aac @ 0000025434729a80] Scalefactor (-2) out of range.
[aac @ 0000025434729a80] Number of scalefactor bands in group (55) exceeds limit (49).
[aac @ 0000025434729a80] Number of scalefactor bands in group (50) exceeds limit (49).
[aac @ 0000025434729a80] Number of scalefactor bands in group (15) exceeds limit (14).
[aac @ 0000025434729a80] Scalefactor (-1) out of range.
[aac @ 0000025434729a80] Number of scalefactor bands in group (60) exceeds limit (49).
[aac @ 0000025434729a80] Scalefactor (259) out of range.
[aac @ 0000025434729a80] More than one AAC RDB per ADTS frame is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented.
[aac @ 0000025434729a80] channel element 1.15 is not allocated
[aac @ 0000025434729a80] Number of scalefactor bands in group (15) exceeds limit (14).
[aac @ 0000025434729a80] Scalefactor (290) out of range.
[aac @ 0000025434729a80] Scalefactor (256) out of range.
[aac @ 0000025434729a80] Scalefactor (259) out of range.
[aac @ 0000025434729a80] Scalefactor (262) out of range.
[aac @ 0000025434729a80] Number of scalefactor bands in group (56) exceeds limit (49).
[...]

Re: exhale - Open Source USAC encoder

Reply #1238 –
Quote from: C.R.Helmrich on
Anyway, the newest exhale source revision (commit 49517c4d), apart from fixing the preset-f issue and increasing the coding efficiency slightly, includes code which, when activated, allows exhale to encode with up to ~300 kbps (stereo) and up to full CD/broadcast audio bandwidth (24 kHz).

It's interesting that you've seen genuine interest in doing that. I did a tiny  mod a while ago which added the ability to go up to 12, but still capped high frequencies to not go >20kHz for CDDA, because I felt that would be silly. And we have the example of libopus where they don't bother with such potential silliness!

Re: exhale - Open Source USAC encoder

Reply #1239 –
Quote from: 2012 on
Quote from: C.R.Helmrich on
Anyway, the newest exhale source revision (commit 49517c4d), apart from fixing the preset-f issue and increasing the coding efficiency slightly, includes code which, when activated, allows exhale to encode with up to ~300 kbps (stereo) and up to full CD/broadcast audio bandwidth (24 kHz).

It's interesting that you've seen genuine interest in doing that. I did a tiny  mod a while ago which added the ability to go up to 12, but still capped high frequencies to not go >20kHz for CDDA, because I felt that would be silly. And we have the example of libopus where they don't bother with such potential silliness!
If there's a mod that can go down to 6 kbps for stereo and 3 kbps for mono, it must be compared with FhG's one at a similar bitrate.
Like:
Quote
exhale -b 6 input.wav out.mp4
Or:
Quote
exhale lb0 input.wav out.mp4
And in help:
Quote
(lb0-5)  low-complexity, low-bitrate Extended HE-AAC using eSBR and ePS at 2*#+6 kbit/s
(mb0-8)  low-complexity, medium-bitrate Extended HE-AAC using eSBR and ePS at 2*#+18 kbit/s
(-b [bitrate])  specify bitrate for Extended HE-AAC encoding (in kbit/s)
ePS = enhanced Parametric Stereo
And if the quality is better than FhG's one at the same bitrate in a listening test, that must be cheating! :D :D :D :D :D

Re: exhale - Open Source USAC encoder

Reply #1240 –
Thanks for the feedback!

AiZ, do the FFmpeg decoding glitches disappear when you use a lower preset? That may hint at the cause of that issue.

2012, that's interesting! Indeed, coding anything beyond 20 kHz is kind of silly, so I activated full-bandwidth coding only with preset 9 (after all, some may expect full audio bandwidth from a preset claiming "archival quality").
Note, though, that I added some fine-tunings going beyond simply pumping more bits into the encodings. Also, only very very few coding bits are actually spent above 20 kHz. You can verify that by looking at the spectrograms of the decoded - original difference waveforms.

Some more results from my side: current bitrate peak with HA sample Closer to God (edit), ca. 353 kbps with high-rate preset 9. Will update this post later.

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

Re: exhale - Open Source USAC encoder

Reply #1243 –
Report all the USAC decoder FFmpeg bugs on FFmpeg trac page.

Re: exhale - Open Source USAC encoder

Reply #1244 –
Encoded approx. 1100 albums using GCC 15.1.0 compiled exhale.exe with SFB_QUANT_PERCEPT_OPT set to 0, x64. All play perfectly on PC in fb2k and on Android 15 (obviously not with fb2k as it does not play these, unfortunately!).

Edit: Forgot to add the most important bit! This was at q 9.

Re: exhale - Open Source USAC encoder

Reply #1245 –
Hi john33
could you please create complication in 2 flavors on rarewares? Normal and with SFB_QUANT_PERCEPT_OPT=0 ?
 

Re: exhale - Open Source USAC encoder

Reply #1246 –
Quote from: alter4 on
Hi john33
could you please create complication in 2 flavors on rarewares? Normal and with SFB_QUANT_PERCEPT_OPT=0 ?
Will do. It will be tomorrow now. :)