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

Re: exhale - Open Source USAC encoder

Reply #425 –
Quote from: guruboolez on
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
...
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
Awesome, thanks for testing so thoroughly again! The comparison with HE-AAC is perfectly in line with Igor's results, it seems.

I calculated an average score of your results from the Billboard, Classical, and Speech subsets (each weighted by 1/3 into the average) to get a less "killer" sample collection similar to what you had in your 64-kbit/s test and updated my plot from the previous page. Not quite the 3.55 score that I had predicted, but then again, you're an extremely experienced listener ;)
 


Still, at 48 kbit/s stereo, exhale is about 0.2-0.3 score points short of the predicted 3.55. I'll spend the rest of the year checking if a basic SBR implementation would close that gap.

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

Re: exhale - Open Source USAC encoder

Reply #426 –
Quote from: C.R.Helmrich on
I'll spend the rest of the year checking if a basic SBR implementation would close that gap.
Yeah! That sounds great!!
Just a question: does USAC have the SBR tool than HE-AAC? On Poikosoft forum the developer mentioned  something he named enhanced SBR.

Re: exhale - Open Source USAC encoder

Reply #427 –
it isn't integrated.

Re: exhale - Open Source USAC encoder

Reply #428 –
Yes, xHE-AAC supports the SBR tool known from HE-AAC and added a few improvements/extensions to it. That's why it is called enhanced SBR (eSBR). But to clarify: I'm still not sure whether this will, overall, increase the audio quality at this bit-rate. As you (and Igor previously) noted, transient audio parts will likely get a bit worse with SBR since the exhale core audio codec will have to run at 24 or 22.05 kHz. As I said, I'll have to do a basic check first.

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

Re: exhale - Open Source USAC encoder

Reply #429 –
Correct me if I'am wrong or I might be not precise enough, enhanced SBR (eSBR) was considered better than classic SBR at bitrates lower than 48 kbps.
eSBR was only somewhat/slightly better than  SBR at 48 kbps and higher.

exhale uses Noise Filling (NS) as substitution to SBR. NS actually does excelent  in exhale.
[e]SBR does great on average and tonal material but fails noticebly on transients.
Whether eSBR will be beneficial at ~48-64 kbps is a thing to try.

IGF is considerably better than both SBR/eSBR but it's not part of xHE-AAC rather than its successor (MPEG-H 3D audio).


Congratulations to Chris for outstanding performance of exhale  :) :)

Re: exhale - Open Source USAC encoder

Reply #430 –
All correct, I would say. That's also why "basic" SBR functionality should be enough for CVBR mode 0 (if it turns out to improve the quality on average, that is).

I don't think mode 1 would sound better with SBR, that's why I'll focus on mode 0. I'll keep you updated.

P.S.: Thanks very much :)

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

Re: exhale - Open Source USAC encoder

Reply #431 –
I finished a release candidate for exhale version 1.0.8 ("i" release) today. Compared with the last changes about one month ago, only very minor quality tweaking was done (mostly for the Fatboy sample at CVBR modes 8 and 9, see also Igor's recent test).

Changes since exhale 1.0.7 from two months ago:
- minor quality improvements at low and high rates, some license text clarifications
- exhaleApp: slightly improved loudness calculation for low and high sampling rates
- exhaleLib: improved audio quality a bit for the lower and higher-rate CVBR modes
- License: removed references to BSD text, clarified disclaimer and contributor text

The clarifications to the license text are minor and were mostly made to make it simpler and safer for people to contribute to the project.

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

Re: exhale - Open Source USAC encoder

Reply #434 –
I just finalized version 1.0.8 ("i" release, Git commit 8b56192), there was a very minor editorial issue where a "downsampling to 32 kHz" notification print-out was missing when encoding 48-kHz audio at CVBR mode 0. So no changes to the encoding process itself since the release candidate above. I'll tag this release tonight.

The next version 1.0.9 ("J" release) will be a bugfix-only release and the last one in the 1.0.x version path. I'll keep you updated on future development on exhale, which will most likely involve addressing the two things mentioned in exhale's issue tracker (#7 and #11).

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

Re: exhale - Open Source USAC encoder

Reply #435 –
Chris, good to see  that 1.0.8.0 improves that Fatboy sample and hopefully some other transient samples.

Quote from: C.R.Helmrich on
I just finalized version 1.0.8 ("i" release, Git commit 8b56192),
That "i" release could stand for "igor" . For no particular reason   :D

Re: exhale - Open Source USAC encoder

Reply #436 –
Quote from: C.R.Helmrich on
I just finalized version 1.0.8 ("i" release, Git commit 8b56192), there was a very minor editorial issue where a "downsampling to 32 kHz" notification print-out was missing when encoding 48-kHz audio at CVBR mode 0. So no changes to the encoding process itself since the release candidate above. I'll tag this release tonight.

Don't forget to att v1.0.8 to https://gitlab.com/ecodis/exhale/-/releases
;)

Re: exhale - Open Source USAC encoder

Reply #437 –
in the name of Justice!
8b561924

Re: exhale - Open Source USAC encoder

Reply #438 –
Wait is it possible for Mobile Foobar to have USAC support by using the FDK2 decoders on Android?.
Got locked out on a password i didn't remember. :/

Re: exhale - Open Source USAC encoder

Reply #439 –
Intel compiles of exhale-v.1.0.8-8b561924 now available at Rarewares. :)

Re: exhale - Open Source USAC encoder

Reply #441 –
I've now managed to implement a first working (= standard compliant) version of xHE-AAC with SBR. Note that it does not yet sound good because exhale so far doesn't write any meaningful SBR data. Still, I'll share the source code in the hope that some of you have time to test it a bit - the more help I get with testing, the faster I can release this officially. The open test points, focusing on encoding via exhale and playback via e.g. foobar2000 with kode54's packet decoder, are listed below. Please let me know if you encounter any problems.

The support for SBR is currently only published in branch develop of the exhale's GitLab source repository. It provides the new CVBR modes a - g as command-line options for coding with rates as low as ~36 kbit/s stereo (or ~20 kbit/s mono), complementing the existing modes 0 - 6 and activating 2:1 SBR (the core encoder operates at half the input sampling rate). The input sampling rate range supported by exhale when encoding xHE-AAC with SBR is 24 - 96 kHz, inclusive.

Open test points:
  • Encoding via exhale executable:
    - Before frame-wise encoding (progress bar not shown): does it abort without an explanation? Does it print out an error code?
    - During frame-wise encoding (progress bar is shown): does it stop encoding with an error? Does it crash without notification?
    - After completing the encoding (Done is shown): does it crash or warn about something, e.g. that the file may be unreadable?
  • Playback or format conversion:
    - Before playback/decoding: does the player fail to recognize or mistreat the files generated by exhale as being xHE-AAC files?
    - During playback/decoding: does it glitch/stutter/abort/crash? Does seeking through the file cause a glitch/stutter/abort/crash?
    - After playback/decoding: are any errors reported? Does the file sound normal? Is playback between successive files gapless?

Known issues:
  • foobar2000, with kode54's FDK-AAC packet decoder, reports the SBR-enabled xHE-AAC files as "AAC SBR". I've already asked kode54 whether this could be changed to something like "USAC SBR" to avoid confusion. Note that (e)SBR is an integral part of the xHE-AAC toolset and every decoder supports it, therefore it shouldn't be necessary to mention SBR.
    -> Fixed by kode54 in his new version 1.14 of the packet decoder (rel. note). Thanks very much!
  • 88.2 and 96 kHz input sampling rates result in weird encodings with SBR (HF spectral gaps) for CVBR modes d-g. I'll either add a print-out later that, in general, encoding with SBR at those mid and high bit-rates is discouraged since you get better audio quality without SBR. Or I'll simply disallow modes d-g and just offer modes a-c as command-line presets.
    -> Fixed locally on my development PC, will be committed along with the next batch of changes.

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

Re: exhale - Open Source USAC encoder

Reply #443 –
del.

Re: exhale - Open Source USAC encoder

Reply #444 –
Doesn't appear to be fully implemented yet, as I noticed from the source code that doesn't actually generate any SBR data, just fills it out with null info. The resulting files have pretty much nothing but spectral mirroring of the lower frequency data at a lower amplitude. Seems to be valid data, though. Also, Big Sur seems to be able to decode it just fine.

Which you just said, right?

Re: exhale - Open Source USAC encoder

Reply #445 –
Wow, Christmas is coming earlier this year :)

I couldn't resist and I tried few files before going to bed.
• JohnV x64 compiles seems to be fine on my side: no visible encoding issue with foobar2000's converter.
• gapless playback: tested with one disc: gapless was fine (it was mode a & c on 16/44100 files).
• seeking: I hear some glitches/weird short noise on seeking, but it usually appeared once or twice on the same file then can't be reproduced again with the same file.
• no error at the end of playback

I won't talk about sound quality yet as I didn't made blind comparisons. I got ~36kbps with mode a. And my early feeling at this bitrate is enthousiasm :)
 

Re: exhale - Open Source USAC encoder

Reply #446 –
Quote from: kode54 on
Doesn't appear to be fully implemented yet, as I noticed from the source code that doesn't actually generate any SBR data, just fills it out with null info. The resulting files have pretty much nothing but spectral mirroring of the lower frequency data at a lower amplitude. Seems to be valid data, though. Also, Big Sur seems to be able to decode it just fine.

Which you just said, right?
Exactly, that's the behavior I currently expect. I'll try to encode some more reasonable SBR envelope data by the weekend, hopefully that will already make it sound very close to the intended behavior.

Quote from: guruboolez on
I won't talk about sound quality yet as I didn't made blind comparisons. I got ~36kbps with mode a. And my early feeling at this bitrate is enthousiasm :)
With the next changes (maybe already next weekend) feel free to give it a listen at 36 and 48 kbit/s if you're so enthusiastic ;) And thanks for mentioning the average bit-rate you're getting, this is something I forgot to mention in my last post: I'm very much interested in what average bit-rates people get on their music collections even with this early SBR version.

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

Re: exhale - Open Source USAC encoder

Reply #447 –
I hope not to find people here who want to listen to music at 36kbps. In my opinion it is a bitrate that best affects news channels for future FM DRM broadcasts or for spoken podcasts.

In this scenario a low pass filter can attenuate too obvious artifacts or automatically resampling 32khz can get you very close to the bitrates of the features not implemented, but not for musical content. Currently the same result can be obtained with AAC LC by sampling at 16khz, the bitrates used in telephony are reached.

Re: exhale - Open Source USAC encoder

Reply #448 –
Hello,

Quick testing of branch develop 16d3fbac :
- There is life above 11kHz, hurray!  :)
- Numerical options produce (much) higher bitrate than 1.0.8.
- FDK-AAC packet decoder 1.14 seems Ok.

Edit: There's definitively something wrong with non-SBR files generated with this version, I can even ABX them! :D

   AiZ

Re: exhale - Open Source USAC encoder

Reply #449 –
Nicely spotted ;) Yes, I added some more SBR code in branch develop. It's still missing adequate time and frequency resolution, so some material won't sound that great in the high-frequency range. But as AiZ noticed, the SBR data written to the files is now more meaningful, and already quite listenable, at least to my ears. But:
Quote from: AiZ on
- Numerical options produce (much) higher bitrate than 1.0.8.
I cannot reproduce this. For modes 0-9, I actually get almost identical results with 1.0.8 and this version (let's call it 1.1 alpha since it's not yet a release candidate).
Ouch, I had included a quick value test into my last commit. Sorry about that, the new revision 1281acbe should fix this. Let me know if you still get very different results than with 1.0.8 for modes 0-9.

Quote from: celona on
I hope not to find people here who want to listen to music at 36kbps. In my opinion it is a bitrate that best affects news channels for future FM DRM broadcasts or for spoken podcasts.
I agree that CVBR mode "a" shouldn't be used unless it is really necessary to limit the bit-rate so much (as with some Web radio and podcast services, as you mentioned). But with the above 1.1 alpha it actually doesn't sound that terrible, so I recommend you give it a try.

For clarification: when using the SBR modes "a"-"g", do not reduce the input sampling rate. The SBR encoder already does that internally, so you get the best audio quality by just feeding 44.1 or 48 kHz into the exhale application. Regarding the choice of 44.1 or 48 kHz: this is somewhat a matter of taste, so I suggest trying it out. I personally tend towards 48-kHz input with mode "b", for example, but the difference is very subtle.

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