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

Re: exhale - Open Source USAC encoder

Reply #226
For unknown reason, I can't use your x64 compile, John33. But Netranger's x64 is working fine (with the same encoder setting: I only changed the encoder's path). Your previous compiles always worked fine.
Am I alone?

Intel Core i7-3610QM


Code: [Select]
1 out of 1 tracks converted with major problems.

Source: "D:\ABX renaissance\bitrate\Bitrate Test 85CD\A.01. Brahms [Claudio Abbado & Wiener Philharmoniker] 21 Ungarische Tanze (DG, CD, 1983).flac"
  An error occurred while writing to file (The encoder has terminated prematurely with code -1073741795 (0xC000001D); please re-check parameters) : "D:\A.01. Brahms [Claudio Abbado & Wiener Philharmoniker] 21 Ungarische Tanze (DG, CD, 1983).m4a"
  Additional information:
  Encoder stream format: 44100Hz / 2ch / 16bps
  Command line: "C:\CODEC\exhale xHE-AAC\exhaleApp-v.1.0.5b-cd4ebeb1_x64\exhaleApp.exe" 2 "A.01. Brahms [Claudio Abbado & Wiener Philharmoniker] 21 Ungarische Tanze (DG, CD, 1983).m4a"
  Working folder: D:\
 
  Conversion failed: The encoder has terminated prematurely with code -1073741795 (0xC000001D); please re-check parameters

Re: exhale - Open Source USAC encoder

Reply #227
Strange! Both x86 and x64 compiles run normally either stand-alone, or within foobar here. (i7 4790k and Ryzen 7 3700X.)

Re: exhale - Open Source USAC encoder

Reply #228
I tried again: same error
Then I tried with x86 compile or yours (exhaleApp-v.1.0.5b-cd4ebeb1): encoding starts fine. I stopped it.
Finally, I changed again the encoder path in foobar to use x64, same source file, same destination: error

Code: [Select]
1 out of 1 tracks converted with major problems.

Source: "D:\ABX renaissance\bitrate\Bitrate Test 85CD\A.10. VA [Placido Domingo, Carlo Maria Giulini & LA Philharmonic Orchestra] Opern-Gala (DG, CD, 1981).flac"
  An error occurred while writing to file (The encoder has terminated prematurely with code -1073741795 (0xC000001D); please re-check parameters) : "Z:\A.10. VA [Placido Domingo, Carlo Maria Giulini & LA Philharmonic Orchestra] Opern-Gala (DG, CD, 1981).m4a"
  Additional information:
  Encoder stream format: 44100Hz / 2ch / 16bps
  Command line: "C:\CODEC\exhale xHE-AAC\exhaleApp-v.1.0.5b-cd4ebeb1_x64\exhaleApp.exe" 5 "A.10. VA [Placido Domingo, Carlo Maria Giulini & LA Philharmonic Orchestra] Opern-Gala (DG, CD, 1981).m4a"
  Working folder: Z:\
 
  Conversion failed: The encoder has terminated prematurely with code -1073741795 (0xC000001D); please re-check parameters

Re: exhale - Open Source USAC encoder

Reply #229
No issues here with John33's exhale 1.0.5b binaries in foobar2000. Working smooth as usual

Re: exhale - Open Source USAC encoder

Reply #230
both version via foobar (wine) work norm, but as "CLI" via wine(/64) not work by different resons.
upd.
core2duo t5600

Re: exhale - Open Source USAC encoder

Reply #231
Strange! Both x86 and x64 compiles run normally either stand-alone, or within foobar here. (i7 4790k and Ryzen 7 3700X.)
Not sure but  maybe the case that i7 3000 supports AVX only, while i7 4000 does  AVX2.

Re: exhale - Open Source USAC encoder

Reply #232
Strange! Both x86 and x64 compiles run normally either stand-alone, or within foobar here. (i7 4790k and Ryzen 7 3700X.)
Not sure but  maybe the case that i7 3000 supports AVX only, while i7 4000 does  AVX2.
Possibly, but I try to make sure that CPU specific optimisations are not invoked in the compiler, and the compile options used are no different to any of the recent builds so a bit of a puzzle!?!

Re: exhale - Open Source USAC encoder

Reply #233
Same problem as guruboolez; processor is i5-2400, OS Windows 7 Enterprise x64.
--------------------

Re: exhale - Open Source USAC encoder

Reply #234
maybe version of foobar and/or decoder? my case (ok) - 1.5.4/1.12

Re: exhale - Open Source USAC encoder

Reply #235
I have foobar2000 1.54 and 1.12 decoder.
I tried different time ; I even download the archive again and extracted it in a shorter path. I tried different file, different size, basic output path…

Code: [Select]
1 out of 1 tracks converted with major problems.

Source: "D:\essai.wav"
  An error occurred while writing to file (The encoder has terminated prematurely with code -1073741795 (0xC000001D); please re-check parameters) : "D:\essai.m4a"
  Additional information:
  Encoder stream format: 44100Hz / 2ch / 16bps
  Command line: "C:\CODEC\exhaleApp 1.0.5b.exe" 4 "essai.m4a"
  Working folder: D:\
 
  Conversion failed: The encoder has terminated prematurely with code -1073741795 (0xC000001D); please re-check parameters

It's very curious.
Anyway, don't waste your time on this. I'm maybe alone on to have this issue. Previous compiles were all good. And I can use x86 or Netranger's 64 bit for this exhale version. Maybe next compile will be fine again :)
Thanks having checked on your side.

Re: exhale - Open Source USAC encoder

Reply #236
IgorC appears to have been correct. The error code refers to illegal instruction and disassembly of the binary shows it contains AVX2 instructions.

Re: exhale - Open Source USAC encoder

Reply #237
Sorry folks!! Having rechecked the 64bit compile, I realised that I had enabled AVX2 on an earlier test build and completely forget to revert it! So, again, sorry to have caused a problem and the x64 link, above, should now give you a generic build.  :-[

Re: exhale - Open Source USAC encoder

Reply #238
Don't apologise! I owe you so much for all your compiles for more than a decade! Thanks John33 :)

Re: exhale - Open Source USAC encoder

Reply #239
No need to apologise... just to confirm that everything works now. Thanks :)
--------------------

Re: exhale - Open Source USAC encoder

Reply #240
Great, thanks ! :)

Re: exhale - Open Source USAC encoder

Reply #241
Now that 1.0.5 beta allow 44.1 KHz sampling rate with mode 1 at ~64 kbps, I was very curious to check how it sounds. Especially after my big 64 kbps personal blind test.

Few words about the tested samples.
I have tested exhale with 40 samples (in fact, 39 because I included the same sample twice) divided in four groups:
  • Billboard (10 samples): I kept 10 samples from the 25 samples I used in my previous test. I kept the most interesting or pleasing samples to my taste. They are all popular hits from the last years.
  • Classical Music: I decided to keep 10 samples from the 75 tested previously. As I couldn't decide myself which samples I have to keep, I took each 8th sample from the alphabetical list (sample #1, #9, #17, #25…) to get exactly ten samples. Some are excellent, some others are rather uninteresting…
  • Hydrogenaud.io samples: I also decided to increase the number of samples by adding some well-known samples here, used in many listening tests (especially the last 96 kbps public multiformat test)
  • Problem samples: A group of well-known problem samples. Most were tested last month ago in IgorC Public Listening Test: exhale mode 2 44KHz vs 32 KHz.

The first three groups are rather "normal" music or common samples ; the last group is maybe a bit more exceptional and is for the most part pre-echo/smearing oriented. For the anecdote, the sample named "41_30sec" was also include in this last group. I removed it during the test when I noticed that I tested it few hours ago in the group 3…

Listening Test Methodology & bitrate
I only performed one ABX test to check the difference of smearing. For all other samples I only gave a score before testing the next file. There are no anchor and therefore scoring is unconstrained.
Bitrate is nearly the same between 32KHz and  44.1KHz (1 kbps difference on full discs/tracks). Even on short samples the gap is unsignificant (69.1 kbps for 32 KHz and 68.1 for 44 KHz). I can put a bitrate table on demand.




RESULTS





Difference isn't significant from a statistical point of vue. But 44.1 Khz has often a lower score than 32 KHz especially on the first three groups. 44.1 KHz has more distortions, so basic I can't really describe them. The kind of acid sound you can hear since decades on low bitrate/starving encodings. Maybe lowpass (which is stronger than with 32KHz) explain this but I'm quite sure there's something else responsible of this. Sometimes it sounds a bit like a kind of noise reduction. Anyway it's a sound I usually dislike: it's a bit WMA-isch/MPEG-isch.
But when transients are involved in the sample, smearing and pre-echo is usually better with 44.1 KHz than with 32 KHz. But I found a small artifact especially audible on eig sample (I'll describe it on another post).

Now, if I dissociate the three groups of "normal" samples from the last group, the results are a bit different:



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.
I remind: it's a personal listening test and evaluation.


Links

samples are available here:
https://www.dropbox.com/sh/zjephy3g54j4gur/AACjGhM9tabl26n7s4ihYl2Ra?dl=0

Re: exhale - Open Source USAC encoder

Reply #242
To complete my test:

I noticed two curious artifacts.
The first one only occured on 44.1 KHz sampling rate with eig sample.
The sample has several time the same transient sound but with exhale 1.0.5b mode 1 at 44.1 KHz some transients are sounding weird and differently than others.
Here is my log file:

Quote
ABC/HR for Java, Version 0.53a, 18 juin 2020
Testname:

Tester: guruboolez

1L = D:\ABX EXHALE 32-44\Problem 03. eig.exhale v1.0.5b-cd4ebeb1.mode1.44khz.wav
2L = D:\ABX EXHALE 32-44\Problem 03. eig.exhale v1.0.5b-cd4ebeb1.mode1.32khz.wav

Ratings on a scale from 1.0 to 5.0

---------------------------------------
General Comments:
---------------------------------------
1L File: D:\ABX EXHALE 32-44\Problem 03. eig.exhale v1.0.5b-cd4ebeb1.mode1.44khz.wav
1L Rating: 2.5
1L Comment: weird artefacts :
1.60 sec
3.80 sec
6.00 sec
12.5 sec
Much sharper than other file

---------------------------------------
2L File: D:\ABX EXHALE 32-44\Problem 03. eig.exhale v1.0.5b-cd4ebeb1.mode1.32khz.wav
2L Rating: 1.5
2L Comment:
---------------------------------------

ABX Results:

44.1 KHz is sharper than 32 KHz but produces some artifacts at precise moments.
I looked into the spectrum to see if something appears. I made an animated gif.


As you can see in the spectrum there are three attacks. They sound almost identical so we can imagine they should look the same. It's the case for the 32 KHz encoding but the 44.1 KHz shows a much different image for the first attack. There is indeed much more energy or noise after the transient, a bit like post-echo. Is this noise which makes this moment sound so differently? I don't know. Anyway, it's clearly audible I would say. To share the experience I join the encoded m4a files and the decoded one in this post.


Second issue, audible with both 32 and 44.1 KHz encoding: the Glockenspiel sample (it's an MPEG sample IIRC).
My log file:

Quote
ABC/HR for Java, Version 0.53a, 18 juin 2020
Testname:

Tester: guruboolez

1L = D:\ABX EXHALE 32-44\Problem 09. 35_SQAM_glockenspiel_cut.exhale v1.0.5b-cd4ebeb1.mode1.32khz.wav
2L = D:\ABX EXHALE 32-44\Problem 09. 35_SQAM_glockenspiel_cut.exhale v1.0.5b-cd4ebeb1.mode1.44khz.wav

Ratings on a scale from 1.0 to 5.0

---------------------------------------
General Comments:
---------------------------------------
1L File: D:\ABX EXHALE 32-44\Problem 09. 35_SQAM_glockenspiel_cut.exhale v1.0.5b-cd4ebeb1.mode1.32khz.wav
1L Rating: 2.0
1L Comment: low frequency artifacts after each attack
---------------------------------------
2L File: D:\ABX EXHALE 32-44\Problem 09. 35_SQAM_glockenspiel_cut.exhale v1.0.5b-cd4ebeb1.mode1.44khz.wav
2L Rating: 2.5
2L Comment: low frequency artifacts after each attack, stronger I think than previous file (but they seem to mask smearing: it seems sharper).
---------------------------------------

ABX Results:

I really hear some artifacts (but I must say that's at high volume playback, 100% of my laptop and a AKG q701 62 Ω impedence headphone) which sounds like small low/mid frequency "plops" which all comes with all glockenspiel note. I join the m4a files and the original FLAC sample if someone can check. I can't illustrate this phenomenon with a graphical analysis.

Re: exhale - Open Source USAC encoder

Reply #243
Hello, when I convert in foobar2000 from flac image with embedded cuesheet and turn off „Do not convert in multiple threads” option, then there is no errors. But when I turn on this option, then I have errors. When I bit-compare tracks from both conversions I have errors too. My CPU is Intel Core i5-4300U (4 threads).

Re: exhale - Open Source USAC encoder

Reply #244
I noticed two curious artifacts.
The first one only occured on 44.1 KHz sampling rate with eig sample.
Those are exactly the same artifacts which were noticed  on 1.0.4 beta.  But with some important observaitons:
Audible intensity  of different type of artifacts  (plops and pre-echo) seem to swap on different bitrates. Plops artifacts are more ok at 96 kbps but as I can see (and hear as well)  it's less ok at 64 kbps.  And sincerely I haven't submit one single test sample at 64 kbps because lack of time and interest at this bitrate point.

I guess when 96 kbps was tuned then 64 kbps got sorta  untuned. I have seen this happened with some codecs in past.

P.S. Not sure what Chris has in plans for exhale but it might be useful to have in mind most popular bitrate points of Opus as this codec and exhale have similar compresison efficiency https://hydrogenaud.io/index.php?topic=115386.0
Sure, ideally all bitrate points should be tuned as much as possible, but  resources as time are always [very] limited. So it's good to define priorities (personal or someone else's) :)

Re: exhale - Open Source USAC encoder

Reply #245
Great work!

Anyone else running into issues compiling this for aarch64 (runs fine on amd64)?
https://pastebin.ubuntu.com/p/mBb3D9ZrRK/

FreeBSD 13-CURRENT, aarch64 (rockpro64) using cmake

Re: exhale - Open Source USAC encoder

Reply #246
Great work!

Anyone else running into issues compiling this for aarch64 (runs fine on amd64)?
https://pastebin.ubuntu.com/p/mBb3D9ZrRK/

FreeBSD 13-CURRENT, aarch64 (rockpro64) using cmake

Looks like the infamous "char is unsigned on ARM" issue. Maybe, as a simple experiment, try to replace all `char` occurrences  with `int8_t` and see what happens?

Re: exhale - Open Source USAC encoder

Reply #247
Hello, when I convert in foobar2000 from flac image with embedded cuesheet and turn off „Do not convert in multiple threads” option, then there is no errors. But when I turn on this option, then I have errors. When I bit-compare tracks from both conversions I have errors too. My CPU is Intel Core i5-4300U (4 threads).
That seems to be an issue not so easy to fix (the error value that the encoder returns means "file I/O error"). I'll have to take a look at that later this year, sorry.
I guess when 96 kbps was tuned then 64 kbps got sorta  untuned. I have seen this happened with some codecs in past.
So far I haven't done many CVBR mode specific tunings, so I'm quite sure this is not the case. It's just too low of a bit-rate for 44.1 kHz sampling rate, I would say.
Looks like the infamous "char is unsigned on ARM" issue.
Oh, ARM support hasn't been on my radar at all! If you find a fix, please let me know!

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

Re: exhale - Open Source USAC encoder

Reply #248
A release candidate version of exhale 1.0.5 has been made available today, see
https://gitlab.com/ecodis/exhale

Changes since the beta version of exhale 1.0.5 from last week:
- changed the names of the release-mode Visual Studio output executables from "exhaleApp.exe" to "exhale.exe", for consistency with CMake behavior (thanks to NetRanger for reporting this!)
- fixed writing of the creation and modification times into the MPEG-4 file header, the previous timestamps were exactly 1970-1904 = 66 years in the past (thanks to kamedo2 for reporting this!)
- fine-tuning of the average bit-rate resulting from 44.1-kHz coding at CVBR mode 1, it was 1 kbit/s lower than that resulting from 32-kHz coding (thanks to guruboolez and m14u for checking!)
- print a warning message when CVBR mode 1 is used with 44.1 kHz input, since guruboolez's personal test verifies that 44.1 kHz sounds worse than 32 kHz on average (thanks a lot for testing!)
- added automatic 2x upsampling of low sampling rates (fs) at high bit-rates when CVBR mode > fs / 4000. To reach the given target rate, the CVBR mode is increased by one when upsampling
- minor speed-up when encoding 22.05 or 24 kHz and automatic upsampling is not used, and a few other minor editorial changes here and there.

What I haven't yet been able to take a look at is the issue reported by AiZ here. I suspect that the WAVE files which exhale doesn't like are Broadcast/Extensible-WAV format files, which is a format exhale currently doesn't support. Can anyone confirm this?

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

Re: exhale - Open Source USAC encoder

Reply #249
Guys, exhale CVBR mode 9 is better than QAAC CVBR 192? :o