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

Re: exhale - Open Source xHE-AAC encoder

Reply #275
From July anyone can download beta versions of Apple software for free
Thanks for the information, let's see if afconvert will be freely accessible then as well, at least for a short time.
I don't know about whatever public beta they have planned for July, but the first Developer Beta I have now, refuses to encode xHE-AAC with afconvert. It is not a problem with the source material. It just outright refuses to accept the default settings, and I don't see any documentation of what bitrates or settings they support.

when scanning for ReplayGain with foobar2000, that track peak value on converted files is never above 0.98 which is a good thing (I think). Usually other lossy like vorbis/opus/mp3 end up with peak values above 1.00.
This is a feature of the xHE-AAC decoding standard and kode54's packet decoder in particular, it applies a limiter to the decoded waveforms at -0.1 dBFS.
Not just a feature of the encoding standard. The decoder I use literally can't output over ±1.0. Android's decoder library outputs 16 bit integer PCM. It can be configured at compile time to output 32 bit integer PCM, also with the same range limit, at the expense of also doing all the fixed point math in 32/64 bit precision instead of just 32 bit.

The only way this will ever change is if there are system codecs which don't suck.

foobar2000 for Mac has also recently added USAC support, using system codecs, so that functionality requires Catalina or newer. Apple's system codecs don't suck. Microsoft's kind of do, and they also don't support USAC yet, with no announced plans for support that I've seen anywhere.

We're limited to either system codecs or FDK-AAC. System codecs *may* support unclipped output, except on Android, and FDK-AAC anywhere else does not.

Re: exhale - Open Source xHE-AAC encoder

Reply #276
Not just a feature of the encoding standard. The decoder I use literally can't output over ±1.0. Android's decoder library outputs 16 bit integer PCM. It can be configured at compile time to output 32 bit integer PCM, also with the same range limit, at the expense of also doing all the fixed point math in 32/64 bit precision instead of just 32 bit.
Thanks for the clarification! Would it be possible for you to, without much extra work, share such a 32-bit version of your packet decoder for me to test? exhale theoretically can encode dynamic ranges of more than 120 dB, but due to the rounding to 16 bits during decoding, it's hard for me to figure out if things work properly in very quiet signal passages during encoding. The increase in the required decoding resources wouldn't be an issue for me, your packet decoder already runs at almost 100x realtime per thread.
Quote
Apple's system codecs don't suck. Microsoft's kind of do, and they also don't support USAC yet, with no announced plans for support that I've seen anywhere.
This is an interesting point. Microsoft added FLAC decoding support a few years ago, so maybe they would be open to support xHE-AAC decoding, especially now that Apple and Google support it. There is a Feedback Hub in Windows 10 which allows to search for, and add new, feature requests to "improve the Windows experience". Maybe someone has already requested it there or could do so if not?

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


Re: exhale - Open Source xHE-AAC encoder

Reply #278
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 #279
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 #280
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 #281
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 #282
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 #283
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 #284
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).

 
SimplePortal 1.0.0 RC1 © 2008-2020