Skip to main content
Topic: exhale - Open Source xHE-AAC encoder (Read 28739 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: exhale - Open Source xHE-AAC encoder

Reply #275
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,

I just tried piping using the RC5 binaries just posted above, and while it works now without the extra ffmpeg flags, it fails on some files now, whereas previously it worked on all files when using the ffmpeg flags.  The error message displayed says "audio too short", and I don't know if it is significant but one thing I noticed that was common between all the files that it did fail on was that it always failed after 5kb, but that may just be the chunk size it reads IDK. If it helps here is an excerpt of one of the error messages (BTW the files it fails on were all 3+ min long):

Code: [Select]
 ERROR while trying to encode input audio data! The audio stream is too short!

av_interleaved_write_frame(): Broken pipe
Error writing trailer of pipe:: Broken pipe
size=       5kB time=00:00:00.07 bitrate= 497.6kbits/s speed=15.7x
video:0kB audio:9kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
Conversion failed!

Re: exhale - Open Source xHE-AAC encoder

Reply #276
Thanks for rechecking! For clarification: does it still work on all of your tested files when specifying the additional ffmpeg flags?

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

 

Re: exhale - Open Source xHE-AAC encoder

Reply #277
After further testing just now though, strangely this issue seems intermittent.

With the exact same audio file, same batch file launcher, same version of exhale, run repetitively, it fails sometimes, and works other times???  I am confused, about every approx 5th attempt with everything EXACTLY the same (input audio, ffmpeg/exhale version all matching etc), it does actually work, and I've tested both both with/without the flags same result.

Re: exhale - Open Source xHE-AAC encoder

Reply #278
OK, this issue seems to be somehow related to the one guruboolez reported yesterday. I'll also contact you privately with a possible fix of which I don't know if it will fully cure the issue (that's why I don't want to change the source code at this point, without being sure).

Update: After some googling, I found that, as an alternative to Windows' _read function which I'm currently using, there's fread which, apparently, does the same but the documentation notes that the latter "locks out other threads". I'm new to those specifics, does anyone know if using fread (or fread_s) instead of _read would solve the stdin issues reported by guruboolez and Ohdengoh?

Edit: I found a "fix" which works for both guruboolez and Ohdengoh. I disabled buffered reading of the WAVE input by changing line 17 of source file src/app/basicWavReader.h to
Code: [Select]
#define BWR_BUFFERED_READ        0 // faster reader
So if you're compiling exhale yourself and you run into problems when using exhale through foobar2000 or ffmpeg, try changing that line as well. I don't really like this change, though, since it slows down the reading unnecessarily, especially when encoding WAVE files via the command-line (instead of stdin), so I decided not to include it into the 1.0.5 release. I'll work on it some more for version 1.0.6 and hope to get a better fix done.

So that means that John's RC5 version is actually the final version 1.0.5, the "F" release. But John, please include the latest Release.htm and rename the executable to exhale.exe, since that's now the intended compiler independent naming.

On a personal note: people, I'm impressed :) Half a year after the first public release of exhale, the project is in a much more stable and compatible state than I expected at this point in time. That's mainly because many of you contributed a lot of testing and listening effort. Thanks a lot, and keep doing so in the future, please :)

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

Re: exhale - Open Source xHE-AAC encoder

Reply #279
exhale 1.0.5 (x64) compiles and runs nicely on Linux. I dimly remember there being an issue with FFmpeg pipes so I tested the following  on a flac file:

Code: [Select]
ffmpeg -i luckynight.flac -f wav pipe:1 | exhale 5 testing.m4a

This worked without error and as well I learnt a little more about the required piping syntax for FFmpeg; always a good day when you learn something new  :D.

Now if only there was playback for these files using a native Linux application...

Re: exhale - Open Source xHE-AAC encoder

Reply #280
Now if only there was playback for these files using a native Linux application...

If I may intrude, what about fb2k mobile of xHE support because that would be nice too :)
"Something bothering you, Mister Spock?"

Re: exhale - Open Source xHE-AAC encoder

Reply #281
Update: After some googling, I found that, as an alternative to Windows' _read function which I'm currently using, there's fread which, apparently, does the same but the documentation notes that the latter "locks out other threads". I'm new to those specifics, does anyone know if using fread (or fread_s) instead of _read would solve the stdin issues reported by guruboolez and Ohdengoh?
read() can result in partial read (especially when reading from network or pipe). Therefore, code like this is not good:
Code: [Select]
  if ((m_bytesRead = _READ (m_fileHandle, b, FILE_HEADER_SIZE)) != FILE_HEADER_SIZE) return false; // error
Instead of giving up, you'd have to repeat reading until all bytes are read. Practically, you have to write some wrapper function around read() to do that.
As for fread(), it does repeated read by default. So, no need to write wrapper.

And one more note: If I remember correctly, fseek(), lseek() or something doesn't return -1 on attempt to seek pipe on Windows.
Therefore, testing seekability by seeking doesn't work properly on Windows. Instead, we have to test if the file is regular file (using stat() or something).

Re: exhale - Open Source xHE-AAC encoder

Reply #282
If I may intrude, what about fb2k mobile of xHE support because that would be nice too :)
Already does, on iOS 13 and newer. No clue what magic would be needed to get that working on Android.

Re: exhale - Open Source xHE-AAC encoder

Reply #283
Already does, on iOS 13 and newer. No clue what magic would be needed to get that working on Android.
Me neither, on Android 9 it can playback xHE from a generic file manager but not from the fb2kmobile app. I should get to the correct forum.
"Something bothering you, Mister Spock?"

Re: exhale - Open Source xHE-AAC encoder

Reply #284
This time, 32KHz is statistically better for the 30 first samples. 44.1 KHz looks stronger on problem samples which is mainly due to its lesser pre-echo.
Interesting observation. It puts previous 80 kbps test into perspective. I'm doing some additional test at 80 kbps and 32 kHz isn't that much worse than 44.1 kHz on non-killer samples. I guess it's also matter of preference: better overall performance vs better handling of corner cases (killer samples), this one last can be quite noticeable.

It's clear from your test that 32 kHz is an optimal sampling rate for exhale@64ks. Also 80k > 64k so differences between two sampling rates (32 vs 44 kHz)  are considerably smaller.

P.S. There is another difficult sample which (I think) is similar to 'Linchpin' as exhale produces similar pattern of artifacts (smearing + pre-echo) AND doesn't increase bitrate much, hence kinda doesn't detect as a 'difficult' to encode.
Sample is attached.

Re: exhale - Open Source xHE-AAC encoder

Reply #285
- exhale doesn't like WAV files above 16/48 written by ffmpeg (16/88.2, 24/44.1 or 24/88.2).
- exhale doesn't like 24-bit WAV files written by sox.
I just added basic support for mono and stereo, 24-bit and 32-bit "extensible" WAVE files in commit 92e14850, so this should be fixed. If not, please let me know.

read() can result in partial read (especially when reading from network or pipe). ...
Instead of giving up, you'd have to repeat reading until all bytes are read. Practically, you have to write some wrapper function around read() to do that.
...
If I remember correctly, fseek(), lseek() or something doesn't return -1 on attempt to seek pipe on Windows.
Therefore, testing seekability by seeking doesn't work properly on Windows. Instead, we have to test if the file is regular file (using stat() or something).
Thanks very much for the clarification. Indeed, the seek related code didn't work on stdin, just reading input instead of seeking in it with stdin was one of the last fixes towards the 1.0.5 release.

Interesting observation. It puts previous 80 kbps test into perspective. I'm doing some additional test at 80 kbps and 32 kHz isn't that much worse than 44.1 kHz on non-killer samples. I guess it's also matter of preference: better overall performance vs better handling of corner cases (killer samples), this one last can be quite noticeable.
...
P.S. There is another difficult sample which (I think) is similar to 'Linchpin' as exhale produces similar pattern of artifacts (smearing + pre-echo) AND doesn't increase bitrate much, hence kinda doesn't detect as a 'difficult' to encode.
Thanks! Yes, this issue will also be fixed once I find a good solution for the Linchpin issue.

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

Re: exhale - Open Source xHE-AAC encoder

Reply #286
Exhale uses a variant of PNS  as sort of  replacement to SBR at low bitrates.
So I've tested it at 64 kbps

Files

  • No modern codec@64 kbps could perform as good as LAME MP3 V5 (~128 kbps).
    It's important to note that first 2 seconds of LAME samples should not be tested because the encoder requires adapt itself and hence this period isn't representative.
    Previously I've made some test and observed that both Opus/exhale@80 kbps are on par with LAME V5
  • Exhale w/PNS performs on par with HE-AAC encoders at 64 kbps
  • This time  samples weren't killers but selected from different albums/different musical genres from my extensive collection.I've stopped at 12 samples as results have converged very quickly



Thanks! Yes, this issue will also be fixed once I find a good solution for the Linchpin issue.
Great. Thank you too. So I count on it. No pressure  :D


Re: exhale - Open Source xHE-AAC encoder

Reply #287
version of opus used? 1.3, 1.3.1 or libopus latest to now 2020-06-28?
1.3 sounds the best to me even if it has difficulty at encoding the details.

Re: exhale - Open Source xHE-AAC encoder

Reply #288
Exhale w/PNS performs on par with HE-AAC encoders at 64 kbps

[This time  samples weren't killers but selected from different albums/different musical genres from my extensive collection.I've stopped at 12 samples as results have converged very quickly

Highly interesting! Thank you for this test :)
It's very intersting to see (again) USAC competitive with SBR-AAC without using SBR. SBRed-USAC can be listened on webradios here. I guess SBR is enabled because sound has typical SBR artifacts.

The comparison between three HE-AAC encoders is also precious. Good overall performance of FDK-AAC. On my side with classical music (full albums) FHG-AAC (Winamp's encoder) reaches 59 kbps on average and FDK-AAC 69 kbps with both VBR mode 2. The latter benefits from a bitrate boost which may explain the superiority. Anyway it's good to see that FDK is similar if not better than FHG :)
Using Apple's encoder even if it's not TVBR seems to be the best solution for testing HE-AAC at the best level.

On this test Opus is also not significantly better than HE-AAC at 64 kbps, which is also interesting to note.

Re: exhale - Open Source xHE-AAC encoder

Reply #289
Using Apple's encoder even if it's not TVBR seems to be the best solution for testing HE-AAC at the best level.
On this test Opus is also not significantly better than HE-AAC at 64 kbps, which is also interesting to note.

I believe that Opus is better than the Apple HE-AAC encoder because it worsens at lower bitrates, but at the same time I am convinced that these comparisons don't make sense anymore, Apple's best encoder at these bitrates is definitely ELD-AAC v1 or v2 (aacf or aacg), despite use LD-SBR.

Re: exhale - Open Source xHE-AAC encoder

Reply #290
I believe that Opus is better than the Apple HE-AAC encoder because it worsens at lower bitrates, but at the same time I am convinced that these comparisons don't make sense anymore, Apple's best encoder at these bitrates is definitely ELD-AAC v1 or v2 (aacf or aacg), despite use LD-SBR.
I'm not sure to understand. Every encoder is getting worse at lower bitrate so I don't understand what you mean.

I must say that I don't know ELD-AAC. Is the format compatible with common AAC profile (LC-AAC, HE-AAC)? Using HE-AAC as competitor makes a lot of sense to me because the format is widely supported. Are there tests available?

Re: exhale - Open Source xHE-AAC encoder

Reply #291
I must say that I don't know ELD-AAC. Is the format compatible with common AAC profile (LC-AAC, HE-AAC)? Using HE-AAC as competitor makes a lot of sense to me because the format is widely supported. Are there tests available?

The decoder for xHE-AAC also decodes the previous formats and the Apple ELD-AAC encoder is present in all versions of MacOS after 10.7 (Lion) which can only decode it. I am also curious to know your opinion, send me the tracks to compress so you can evaluate them yourself. I also use AAC in general because today you can't transcode a file for each destination and you can't distribute formats that for 20% of your users don't work right away.

Re: exhale - Open Source xHE-AAC encoder

Reply #292
ELD-AAC where ELD stands for enhanced low delay. ELD-AAC is a low delay version of HE-AAC. 
As ELD-AAC  is low delay codec (32ms)  and  it doesn't reach quality of HE-AAC wich has no delay constraints (100-200ms).
ELD v2 is ELDv1 + low delay PS so it's still less efficient than HE-AACv2.

ELDv1/v2 is for real time applications which require low delay. It's main task is low delay, so it means that quality is a second priority hence it's not as good as HE-AACv1/v2.


@celona
Please use google  and get your facts right next  time before saying  that someone's labour is useless, alright?
ELD-AAC is clearly inferior comparing to HE-AAC. Here is an information https://www.iis.fraunhofer.de/content/dam/iis/de/doc/ame/conference/AES-125-Convention_AAC-ELD-NewStandardForHighQualityCommunication_AES7503.pdf

version of opus used? 1.3, 1.3.1 or libopus latest to now 2020-06-28?
It was latest and greatest 1.3.1
Regarding new builds,  libopus 1.3 (Oct 18, 2018) was the last build which contained improvements of audio quality. No more quality improvements since 2018, capisce? https://github.com/xiph/opus/commits/master
All newer builds contain fixes, new features related to  programme itself but  there are no audio quality enhancements for the way  which most of us use the codec.


Highly interesting! Thank you for this test :)
The comparison between three HE-AAC encoders is also precious. Good overall performance of FDK-AAC. On my side with classical music (full albums) FHG-AAC (Winamp's encoder) reaches 59 kbps on average and FDK-AAC 69 kbps with both VBR mode 2. The latter benefits from a bitrate boost which may explain the superiority. Anyway it's good to see that FDK is similar if not better than FHG :)
Using Apple's encoder even if it's not TVBR seems to be the best solution for testing HE-AAC at the best level.
I see. Well, FDK produces way higher bitrate than target 64 kbps.   Aslo Apple CVBR is kindy tricky to test. I don't know if You remeber we have seen and You have posted about it too that Apple CVBR produces higher bitrate during first 5 seconds and then  in order to keep bitrate  it can go deep down (eig is a good sample to see how quality/bitrate varies drastically ). I was careful enough to test the whole samples.  On the other hand, exhale hits target bitrate without issues and doesn't do tricks behind. So it's a good achivement for exhale to be on par with HE-AAC encoders with such bitrate behavior.

Re: exhale - Open Source xHE-AAC encoder

Reply #293
Talking about opus, Libopus 1.3 is still the best sounding and more stable, less generation loss in my opinion for example at 169 kbps. Even 1.3.1 is good enough. But I don't know what YT use. Opus still can have improvements in the 71 kbps or 116 kbps range.
The FFmpeg Zeranoe build is a bit slow (about 1 minute) even if is newer. For comparison Opus 1.3.1-41 takes 25 seconds for 48 minutes of music with 2 threads.
But don't know if they were speed optimizations after 1.3..
64 kbps is very low, if you want 86 kbps peaks for example.

Re: exhale - Open Source xHE-AAC encoder

Reply #294
eig fatboy is a good sample to see how quality/bitrate varies drastically ). I was careful enough to test the whole samples.  On the other hand, exhale hits target bitrate without issues and doesn't do tricks behind. So it's a good achivement for exhale to be on par with HE-AAC encoders with such bitrate behavior.


Re: exhale - Open Source xHE-AAC encoder

Reply #296
I see. Well, FDK produces way higher bitrate than target 64 kbps.   Aslo Apple CVBR is kindy tricky to test. I don't know if You remeber we have seen and You have posted about it too that Apple CVBR produces higher bitrate during first 5 seconds and then  in order to keep bitrate  it can go deep down (eig is a good sample to see how quality/bitrate varies drastically ). I was careful enough to test the whole samples. 
FDK is a bit higher than 64 kbps, and FHG is a bit lower. Comparing each against any 64 kbps contender is not a problem in my opinion; but comparing each other may be more questionable.

Quote
On the other hand, exhale hits target bitrate without issues and doesn't do tricks behind. So it's a good achivement for exhale to be on par with HE-AAC encoders with such bitrate behavior.
It's exactly my point. SBR has a positive effect on overall quality when bitrate starvation occurs; but SBR also lead to artefacts on its own. So keeping a similar quality without SBR is a very good thing. OPUS has a different encoding technique than SBR which also bring serious issues. It was very clear by testing classical music but sound quality but much less with louder music.

Re: exhale - Open Source xHE-AAC encoder

Reply #297
OPUS has a different encoding technique than SBR which also bring serious issues. It was very clear by testing classical music but sound quality but much less with louder music.
Opus has 'band folding' which is similar SBR but it's not a cause of low performance on classic music.  If that was a case then 'band folding' would perform bad  on your set of 25 smaples of popular music.

It's low-overlap design to keep low-delay.  Pretty every low delay format suffers from lower frequency resolution (those harsh artifacts)

Sorry, we're  offtopic here.  Next time I'll open a new topic for my personal tests.
Let's back to exhale


Re: exhale - Open Source xHE-AAC encoder

Reply #298
Hello,

I just added basic support for mono and stereo, 24-bit and 32-bit "extensible" WAVE files in commit 92e14850, so this should be fixed. If not, please let me know.

Just have tested it with previous problematic files and some on-the-fly FLAC to WAV conversions with ffmpeg (without additional metadata-related parameters) piped in exhale: all went Ok. Thanks!  :)

    AiZ


 
SimplePortal 1.0.0 RC1 © 2008-2020