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,

 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!

#define BWR_BUFFERED_READ        0 // faster reader

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

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

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?

  if ((m_bytesRead = _READ (m_fileHandle, b, FILE_HEADER_SIZE)) != FILE_HEADER_SIZE) return false; // error

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.

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.

- 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.

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).

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.

• 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.

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

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.

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?

version of opus used? 1.3, 1.3.1 or libopus latest to now 2020-06-28?

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.

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.

I am also curious to know your opinion, send me the tracks to compress so you can evaluate them yourself.

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.

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.

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.