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

Re: exhale - Open Source USAC encoder

Reply #50
Are you encoding at a different sampling rate?
Yes, exactly. 24khz for mode 1 and 32khz modes 2 through 9. Did I misread those were the maximum sample rates for those modes? Or maybe that was just for version 1.0.2.
"Something bothering you, Mister Spock?"

Re: exhale - Open Source USAC encoder

Reply #51
Destroid,

exhale doesn't need resampling starting  from CVBR mode 3 (~96 kbps) all way up to  mode 9 (~192 kbps). 
Even decent LC-AAC encoders  does 44.1 kHz (without resampling) at 96 kbps and higher. Add to it that  xHE format has higher compression efficiency than LC-AAC at any rate.  So it wont be bad idea  to keep 44.1 kHz even for mode 2.

I am sorry if I am intruding, but what is this codec, exactly? Some sort of upgrade over traditional LC-AAC codecs? Are old AAC decoders capable of decoding this stream? I've tested few songs, and at L3 they sound OK, I didn't do any ABX, will wait for a bit for that.
Your apology is unnecessary :)
Basically exhale  is an encoder of a newer generation audio standard USAC/xHE-AAC, which is not the same thing as LC-AAC nor HE-AAC.
Here You will find the answer. https://hydrogenaud.io/index.php?topic=118888.msg982087#msg982087

IgorC, thanks a lot for your careful listening above! I analyzed your encodings and comments and released exhale version 1.0.3 today, see https://gitlab.com/ecodis/exhale/-/releases/v1.0.3
Great!

If somebody could submit a few tests or observations that would be even better and more representative.

Re: exhale - Open Source USAC encoder

Reply #52
@IgorC
Thanks for getting me on track. When I first started benching with 1.0.2 I saw mode 2 warning and made a bad assumption.

Here's the summary of re-testing:
Code: [Select]
mode         exhaleApp       exhaleApp      exhale GCC
   sample    1.0.2 x86       1.0.3 x86      1.0.3 win32
   rate     kbps  speed     kbps  speed     kbps  speed
-- -----   ------ ------   ------ ------   ------ ------
1  24kHz    68.74  6.80x    64.42  7.38x    64.37  7.47x
2  44kHz    79.44  9.70x    75.82 10.12x    75.82 10.92x
3  44kHz    96.73  8.64x    94.34  8.87x    94.34  9.52x
4  44kHz   114.71  7.86x   106.50  8.34x   106.50  8.89x
5  44kHz   131.36  7.08x   121.91  7.90x   121.91  8.34x
6  44kHz   150.47  8.57x   133.35  9.57x   133.35 10.27x
7  44kHz   159.69  8.37x   148.19  9.14x   148.19  9.79x
8  44kHz   179.60  8.16x   166.88  8.83x   166.88  9.4x1
9  44kHz   192.47  8.06x   179.19  8.67x   179.19  9.15x
Interestingly (to me) are the encode speeds are much faster with 44kHz than 32kHz sources.

I'll stop clogging this thread with speed benchmarks to get on with the real testing (the listening tests, that is until I read about new speed improvements :) ). Mostly I've tinkering with scripts during a time when performing live shows is not happening much.

@AiZ
Thanks for the updated binaries. I know it's not fun to support outdated OS'es. I like that GCC has a performance edge on the 32-bit platform. :)

@john33
Another thanks for the update, as always you're awesome with getting compiled out there. :)
"Something bothering you, Mister Spock?"

Re: exhale - Open Source USAC encoder

Reply #53
Yes, exhale allows encoding 44.1-kHz audio starting at CVBR mode 2. In fact, it can handle up to 96 kHz sampling rate from mode 3 or 4 upwards, with a maximum coded audio bandwidth of 27 kHz at mode 4 and 96 kHz input which increases by 3 kHz with each further mode (i.e., up to 42 kHz at mode 9). I don't recommend using exhale that way, though. Just fyi, for the curious or secret audiophiles among us ;)

Unfortunately, I broke that feature some time ago (causing exhale to crash on >48 kHz sampling rates) and had to commit a fix today. John33, AiZ: fyi, since that fix doesn't seem to change "normal" encoding in any way, I'll probably move the 1.0.3 release tag soon to include that high-sampling-rate fix.

Destroid, your testing is much appreciated! In fact, it led me to check more sampling rates as input, and to get them working again :) For completeness of your testing, would it be possible for you to post your mean bit-rates for only the Dire Straits album, so I can cross-check with my results?

Btw, 32-kHz audio triggers a different encoding speed level than higher sampling rates, so that speed difference is somewhat intended.

Quote
So it wont be bad idea to keep 44.1 kHz even for mode 2.
That's actually something I'm trying to figure out currently: What sounds better with mode 2 on average, 44.1 or 32 kHz sampling rate? So all those for whom evaluating mode 3 is too difficult, feel free to focus on mode 2 now.

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

Re: exhale - Open Source USAC encoder

Reply #54
Ok,

John33, AiZ: fyi, since that fix doesn't seem to change "normal" encoding in any way, I'll probably move the 1.0.3 release tag soon to include that high-sampling-rate fix.
Archive updated with current master.

    AiZ

Re: exhale - Open Source USAC encoder

Reply #55
@C.R.Helmrich

I have the average bitrates for "Brothers In Arms." Note the results are those reported by exhaleApp.exe (more about this below):
Code: [Select]
mode Track1 Track2 Track3 Track4 Track5 Track6 Track7 Track8 Track9
     +3.60  +3.29  +3.29  +6.27  +10.92 +5.44  +3.81  +2.48  +5.81
--   -----  -----  -----  -----  -----  -----  -----  -----  -----
1     66.8   67.1   61.2   66.5   63.5   67.3   66.6   65.4   63.0
2     79.1   79.1   76.6   82.7   81.4   84.0   80.3   80.2   80.7
3     99.5   98.4   94.0  100.6  100.1  104.6  100.0   97.1   99.6
4    111.9  110.0  103.6  111.5  110.8  117.4  112.1  107.4  110.3
5    131.0  128.6  120.4  128.8  129.2  138.1  131.0  122.9  129.5
6    144.0  140.8  132.0  140.4  141.3  151.0  143.4  133.5  142.2
7    161.0  157.1  147.8  156.5  157.7  167.8  159.8  148.8  159.1
8    180.2  175.7  165.4  175.7  175.6  187.5  179.0  166.5  176.5
9    193.6  188.7  178.2  188.9  188.9  201.1  192.2  178.8  189.9

Note: The replaygain values in the table for each track were derived from the WAV files scanned Foobar2000 1.5.1 (no WAV processing except Mode 1 resampled to 24kHz by SoX). I assure any users out there the replaygain values are correct :) (proven by Track5 being the quietest song on the album).

As to the bitrate anomaly,

All my previous benches I reported encoder's speed and bitrates via math equations in my script. Sorry I failed to mention this before.

During the album testing above, I noticed a discrepancy with the bitrate values from the exhaleApp.exe and my script. I think this accounts for the low values you noticed since my script is agnostic to the values outputted by the encoder. I had written the script to account for any encoder lacking to report speed ( WAV_duration / encoder_time ) or bitrate (below), or just simply the binary does not output to CON via redirect ( > or >>). In this case, the discrepancy of my script is based on my equation:

bitrate = ( xHE_filesize * 8 ) / ( WAV_total_samples / WAV_sample_rate ) / 1024

Obviously the last constant caused the discrepancy, and is exacerbated by higher bitrate modes. Also, there's a slightly lower average bitrate for not taking in account the file container/metadata although no tags were entered when encoding strictly from the command line.

Any comments are welcome! (Flames can be sent PM. :) )
"Something bothering you, Mister Spock?"

Re: exhale - Open Source USAC encoder

Reply #56
OK, now we have explanations for everything. No need for flaming ;) Note that, unlike with file sizes, it's common practice to measure data rates in "lower-case kilobits" as multiples of 1000, not 2^10. So multiplying your former bit-rate results with 1.024 leads to bit-rates which are very close to the respective target rates. So everything looks good now, I think. Thanks again for the clarification!

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

Re: exhale - Open Source USAC encoder

Reply #57
del. my bad. wrong resamling.  O:)

Re: exhale - Open Source USAC encoder

Reply #58
Hello,

Being stuck at home, I make silly things. Like encoding samples from this thread, with all released versions of exhale (plus latest commit), at level 3 and list resulting bitrates.

1.0.01.0.11.0.21.0.3a3be5338
41_30sec109110112115114
finalfantasy10110010098101
ATrain106106110114113
BigYellow109110109105105
FloorEssence105106105107108
macabre9695100107107
mybloodrusts97971019596
Quizas103104107110110
VelvetRealm106105108114113
Amefuribana100100101105104
Trust99100102101101
Waiting103103106109109
experiencia107108104101101
HearttoHeart105105108103103
Tom'sDiner115115102104104
1.0.01.0.11.0.21.0.3a3be5338
castanets106107100106106
fatboy_30sec111112111115115
eig99101102114113
Bachpsichord106105111117122
Enola110110108106105
trumpet101100106105102
applaud104106107107107
velvet108109109107107
Linchpin9394959292
spill_the_blood102102106108109
female_speech104105979796
French_Ad104104101103103
I'll (try to) update this post with newer versions.

    AiZ

Re: exhale - Open Source USAC encoder

Reply #59
 AiZ,
Those samples are actually killers so it's normal if encoder codes them at significantly higher rate.
I also have checked  1.0.2.1 and 1.0.3.0 on several albums. Both produce less or more the same bitrate.



Re: exhale - Open Source USAC encoder

Reply #60
Comparison of 1.0.3.0 vs 1.0.2.1 at 96 kbps (CVBR mode 3).

Congrats, Chris, 1.0.3.0 performs very well. Quality is stellar!
exhale is, at least, inline with best encoders .
Thank You for opening the sources of the encoder.

Most of these samples are killlers, so, in a real-life scenario quality is in "excellent" zone for big majority of albums. 
Files on My Drive


Credits for graphmaker are Kamedo2's
https://listening-test.coresv.net/graphmaker4.htm
https://listening-test.coresv.net/graphmaker5.htm




Re: exhale - Open Source USAC encoder

Reply #61
Hi,

Those samples are actually killers so it's normal if encoder codes them at significantly higher rate.
Of course. I was not doing this to say that level 3 encoding was way above 96kbit/s, but to monitor the evolution of Chris' tuning of this wonderful encoder. Hence the use of this kind of samples.

I also have checked  1.0.2.1 and 1.0.3.0 on several albums. Both produce less or more the same bitrate.
Exactly.
I would even go with level 2 setting, more than enough for my hearing and usage.

Have a nice day,

    AiZ

Re: exhale - Open Source USAC encoder

Reply #62
Is there possibility to add this encoder to foobar2000? I tried and miserably failed :)
Error 404; signature server not available.



Re: exhale - Open Source USAC encoder

Reply #65
Hello,
It is explained here.
    AiZ

Jeez, I'm such an eejit! I've been there to see usage for command line :)
Error 404; signature server not available.

 

Re: exhale - Open Source USAC encoder

Reply #66
Interestingly (to me) are the encode speeds are much faster with 44kHz than 32kHz sources.
Indeed, the 32-kHz and 24-kHz encoding was a bit slower than necessary. I changed that last night in the master source.

Of course. I was not doing this to say that level 3 encoding was way above 96kbit/s, but to monitor the evolution of Chris' tuning of this wonderful encoder. Hence the use of this kind of samples.
Thanks, AiZ, for the praise :) And for verifying that I didn't break anything in exhale's bit allocation algorithm recently.

Congrats, Chris, 1.0.3.0 performs very well. Quality is stellar!
exhale is, at least, inline with best encoders .
Thank You for opening the sources of the encoder.
Thanks also to you, Igor, for the praise :) Now that mode 3 seems in good shape, I'll focus on improving mode 2.

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

Re: exhale - Open Source USAC encoder

Reply #67
Of course. I was not doing this to say that level 3 encoding was way above 96kbit/s, but to monitor the evolution of Chris' tuning of this wonderful encoder. Hence the use of this kind of samples.
Yes, You know that.   I was being precautious before anybody would mention about bitrate deviation on some particular sample and aren't familiar how VBR works.

I would even go with level 2 setting, more than enough for my hearing and usage.
It's not only You.   :)  Many people say that 80 kbps is their limit as well (obviously using the last generation codecs Opus and now  xHE-AAC will go that way too) https://hydrogenaud.io/index.php?topic=114656.msg945200#msg945200

Mode 2 (~80 kbps)  is where most of the people might start to perceive something substantial.

Now that mode 3 seems in good shape, I'll focus on improving mode 2
+1

Re: exhale - Open Source USAC encoder

Reply #68
Chris,

Do You consider to add unrestricted VBR mode (true VBR)?  I understand that true VBR would require to dedicate some additional time for its development. CVBR is good for certain cases so is TVBR.

It's not a coincidence that all popular (and good) encoders have unrestricted VBR . LAME, Helix MP3,  Apple TVBR, Vorbis, Opus and I think your FhG AAC encoder from Winamp as well (?). It means it works for the most of people.

LAME V5(~128kbps)  goes up to 320 kbps on a transients frames. That's 2.5x of a target bitrate!

Maybe 15+ years ago CVBR was a big deal though today most of connections are stable and very fast to admit virtually any variation of unrestricted VBR.  For example, I have  4G connection ~10-100 Mbps  on my mobile but  it's capped to 4 GB per month.  So momentary bitrate peaks isn't an issue.  And if  96 kbps TVBR prevents me to go higher, lets say, to CVBR 112 kbps then it's a good deal to use TVBR (even if some files will end up with somewhat higher bitrate)

As for storage, TVBR is way to go as well.

Cheers.

P.S. Mode 2 can benefit from unrestricted VBR as 80 kbps is where a non-parametric coding is  started to being pushed to its limits.

Re: exhale - Open Source USAC encoder

Reply #69
There is some joy for Linux users who are interested in using exhale:

  • Slackware build script: Courtesy of the recent fix for 'compiling with an older gcc' a build script is now in place for Slackware users on SBo, (the home of 3rd party scripts for Slackware).
  • Ubuntu guide:  There is a guide available on Ask Ubuntu that deals with installation and simple usage of exhale.
  • abcde patch: There is a patch against the CD Ripper abcde's git head to enable ripping of audio cds and subsequent encoding using exhale. This has been tested and subsequently submitted to the current abcde developer.

What is missing at the moment in the Linux world is availability of playback. Current solution of using Foobar either with Wine or by using a Virtual Machine is fine but native playback would definitely seal the deal.

Re: exhale - Open Source USAC encoder

Reply #70
DeaDBeeF was supposed to get a decoder based on FDK-AAC, three years ago. It still hasn't seen the light of day.

Therefore, DeaDBeeF's AAC plugin is not only still libFAAD, but it's also not gapless.

Re: exhale - Open Source USAC encoder

Reply #71
Thank you very very much Christian for working on this project!

I played a bit with this yesterday, at mode #3 (~96 kbps) and indeed quality is far from a basic proof of concept tool and is already better than usable. I listened to a full album with headphone and I quickly forgot that I’m listening to lossy below 100 kbps. Artifacts are audible from time to time but it’s still really nice.

I’m currently building a bitrate table with classical music albums only. It’s based on 91 full discs and my CPU isn’t so young; encoding is therefore a bit long. Speed is between ×30 and ×40 on my i7-3610QM@2,30GHz quad-core laptop for over 100 hours of music. I won’t test all 10 presets but I will compare to other lossy VBR encoders for curiosity.
Example: for mode #3, the average bitrate is 99…100 kbps. Extreme cases are 57 kbps for the lowest and 117 kbps for the highest. For mode #2, average is 81 kbps (min: 50kbps — max: 98). Values are those reported by foobar2000.
Just for comparison, Opus 1.31 VBR 96 deviates a bit more on classical music and it reach 103…104 kbps on the full set (min: 73kbps — max: 121).
I'll post a full table when ready.

Something I noticed is exhale behaviour on monophonic albums (three monophonic discs are included in the set). Average bitrate for monophonic is the same than for stereo album with exhale. But other lossy VBR encoders I’m currently testing have all a huge drop in bitrate with these three discs. Is it intended behaviour?

Re: exhale - Open Source USAC encoder

Reply #72
BITRATE TABLE: CLASSICAL MUSIC ONLY (91 discs, over 100 hours)

Code: [Select]
ENCODER   PRESET            |   BITRATE    |                 STEREO
                            |   FULL SET   |    MONO       LOW BITRATE    HIGH BITRATE
                            |   (91 CD)    |   (3 CD)         (4 CD)        (3 CD)
------------------------------------------------------------------------------------
FLAC CUEtools       -8      |  580.2 kbps  |   467.7 kbps   264.0 kbps   1028.7 kbps
------------------------------------------------------------------------------------
exhale 1.0.3 x64    mode 2  |   80.6 kbps  |    85.7 kbps    54.3 kbps     96.0 kbps
exhale 1.0.3 x64    mode 3  |   99.3 kbps  |   100.7 kbps    62.8 kbps    115.0 kbps
exhale 1.0.3 x64    mode 4  |  110.5 kbps  |   110.0 kbps    67.5 kbps    126.7 kbps
exhale 1.0.3 x64    mode 5  |  131.2 kbps  |   123.7 kbps    77.3 kbps    145.3 kbps


Small comparison between exhale mode #3 and other tools at similar target

Code: [Select]
-------------------------------------------------------------------------------------
  (VBR settings ~96 kbps)   |   BITRATE    |                 (stereo)
                            |   FULL SET   |    MONO       LOW BITRATE    HIGH BITRATE
ENCODER            PRESET   |   (91 CD)    |   (3 CD)         (4 CD)        (3 CD)
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
OGG libVorbis I 20150105 q2 |   85.9 kbps  |    72.0 kbps    76.5 kbps    106.3 kbps
MP3 LAME 3.100      V6      |   89.6 kbps  |    60.3 kbps    52.5 kbps    115.7 kbps 
AAC iTunes 7.10.9.0 tvbr45  |   96.8 kbps  |    54.7 kbps    81.0 kbps     99.7 kbps
AAC FAAC 1.29.9.2   -q 120  |   97.4 kbps  |    73.7 kbps    61.0 kbps    158.3 kbps
exhale 1.0.3 x64    mode 3  |   99.3 kbps  |   100.7 kbps    62.8 kbps    115.0 kbps
OPUS 1.3.1 x64      vbr 96  |  103.4 kbps  |    78.7 kbps   104.5 kbps    117.3 kbps
AAC fdkaac 4.0.0 LC mode 3  |  110.6 kbps  |    66.0 kbps    94.0 kbps    108.0 kbps   

In this table you can see that exhale seems quite unefficient with my monophonic records.

_______
About these 91 discs:

I have a very large library with classical music only. Very large means insanely large (the kind of playlist that last several years). Everything is encoded to FLAC (CUETools -8) and the average bitrate for 44.1 KHz/16bit is 581 kbps.
For obvious reason I can’t encode the whole library to get average bitrate for different encoders/settings. Testing means selecting.

Thus my plan was to reduce this huge library to something easier to handle. My first though was to find myself 50 to 100 albums that end with an average bitrate at 581 kbps. But I finally tried something different.
These last 20 years many labels released countless large boxset (All Mozart, All Karajan, Greatest Concerto, 150 years of <choose city> Orchestra, 100 greatest recordings from <label>, etc…). I tried to find one or two boxset and get my ~580 kbps. Bingo! Deutsche Grammophon released a 111 Years anniversary boxset of 55 discs ; Harmonia Mundi a 29 discs anniversary boxset. With both sets I reached 581 kbps (579 kbps on an Excel table). Every classical subgenres and every musical periods are represented. There are three mono albums and recordings from beginning of stereo to 2007. It seems that I found my reference for future tests.

To these 84 CD I also add extreme albums: those which need very little bitrate in lossless (<300 kbps in stereo) and those which requires more than 1000 kbps (which is really rare with classical music). These extremes might be useful to spot how other VBR encoders handles these kind of signals. Consequently I add 4 low bitrate discs and 3 high bitrate discs to the 84 first CD.

The average bitrate for this 91 CD test collection is 582 kbps (weighted by duration) of 580.2 kbps (average values with Excel), values that are very close to my entire library (581 kbps).

Re: exhale - Open Source USAC encoder

Reply #73
Chris, Do You consider to add unrestricted VBR mode (true VBR)?
Short answer: no.
Longer one: The CVBR algorithm already spends 25% more or less than the target bit-rate on some samples, see, e.g., AiZ's statistics above (Bachpsichord sample). That's already more than the ±20% range I initially planned for. Also, apart from such harpsichord samples, I haven't found any other content so far for which, at a sampling rate of 44.1 kHz or more and CVBR mode 3 or less, high sound quality can only be reached by pumping bits into the encoding*. Finally, the "C" in exhale's CVBR algorithm actually does a more subtle job than you might think, see also the following answer.

Average bitrate for monophonic is the same than for stereo album with exhale. But other lossy VBR encoders I’m currently testing have all a huge drop in bitrate with these three discs. Is it intended behaviour?

... exhale seems quite unefficient with my monophonic records.
Thanks very much for testing! This is intended behavior and represents the most noticeable part of the "C" in exhale's CVBR approach. Having said that, it seems to have worked better for modes > 4 than for the lower modes, so I just committed a minor change to the source which reduces the bit-rate on such mono-in-stereo content. Would it be possible for you to recollect your statistics for modes 2 - 4 with the latest Git master version? If you're short on time, doing that only for mode 3 would also be fine.

Chris

* The sound quality on, e.g., the Fatboy and Linchpin samples could, in principle, be improved in different ways, without increasing the bit-rate.
If I don't reply to your reply, it means I agree with you.

Re: exhale - Open Source USAC encoder

Reply #74
Here, have some binaries with that commit added. Built with MSVC 2015, settings modified to use "fast" math, and the 32 bit build modified to use the v140_xp SDK and only IA32 math, so it should technically work on something fairly old.