IPB

Welcome Guest ( Log In | Register )

> foobar2000 General Forum Rules

This is NOT a tech support forum.
Tech support questions go to foobar2000 Tech Support forum instead.

See also: Hydrogenaudio Terms of Service.

2 Pages V   1 2 >  
Reply to this topicStart new topic
qaac.exe and fhgaacenc.exe, difference between foobar2000 and standard versions?
yetanotherid
post Aug 1 2014, 04:09
Post #1





Group: Members
Posts: 39
Joined: 11-August 08
Member No.: 56966



Just out of curiosity......

What's the difference between the standard version of qaac.exe and the version in the foobar2000 encoder pack? They both appear to be version 2.41 but the file sizes are different. 1.0MB v 1.2MB

Same question regarding fhgaacenc.exe They both write the same version information (3.02) but the file sizes are quite different (20kB v 150kB).

It's no big deal. Either version of both encoders work (at least with the custom encoder configurations I created a while ago). I'm just curious.

Thanks.
Go to the top of the page
+Quote Post
kode54
post Aug 1 2014, 05:11
Post #2





Group: Admin
Posts: 4795
Joined: 15-December 02
Member No.: 4082



Possibly rebuilds to dodge the necessity of installing random Visual C++ runtimes. You'll have to wait for an official response for the correct answer.
Go to the top of the page
+Quote Post
Case
post Aug 1 2014, 06:31
Post #3





Group: Developer (Donating)
Posts: 2436
Joined: 19-October 01
From: Finland
Member No.: 322



qaac is just a recompile with statically linked C++ runtimes to make the Encoder Pack smaller and get the program to work on Windows XP SP2.
Bundled fhgaacenc has a few more changes. I fixed a crashing bug on close since the original version used too small buffers with FhG's libraries, added some extra help messages for command line parameters, made it accept 32-bit float input (it gets converted to 32-bit int on the fly) and made it use Activation Context for MSVCR9 runtimes so that it works without installing Visual C++ runtimes. And the size increase is the result of it being statically linked to Visual C++ 2013 runtimes it is compiled with. Almost forgot, the modified version is stripped from libsndfile requirement too as its license is too limiting.

This post has been edited by Case: Aug 1 2014, 07:08
Go to the top of the page
+Quote Post
yetanotherid
post Aug 3 2014, 09:59
Post #4





Group: Members
Posts: 39
Joined: 11-August 08
Member No.: 56966



Wow, thanks for all the info.

I have a few different programs installed capable of using fhgaacenc and qaac and when it comes to multiple programs using the same tools/encoders etc, I try to keep them all using the same versions if possible so they're easier to keep updated, and it's less confusing.....

It sounds like using your flavours of qaac and fhgaacenc with programs which expect the "standard" versions should be fine, so I'll stick with yours.

Thanks.
Go to the top of the page
+Quote Post
lvqcl
post Apr 22 2015, 17:10
Post #5





Group: Developer
Posts: 3730
Joined: 2-December 07
Member No.: 49183



QUOTE (Case @ Aug 1 2014, 08:31) *
made it accept 32-bit float input (it gets converted to 32-bit int on the fly)


I just thought that it is possible to create a custom version of nsutil.dll that allows to pass 32-bit float directly to the encoder...
Go to the top of the page
+Quote Post
Case
post Apr 24 2015, 06:34
Post #6





Group: Developer (Donating)
Posts: 2436
Joined: 19-October 01
From: Finland
Member No.: 322



I'd be interested to try using such a thing if you have the time to create it.
Go to the top of the page
+Quote Post
lvqcl
post Apr 24 2015, 18:24
Post #7





Group: Developer
Posts: 3730
Joined: 2-December 07
Member No.: 49183



Well, here it is: [attachment removed]

How to use it:
1) Load nsutil.dll
2) Get the address of nsutil_mod_InputIsFloat32 function. If it doesn't exist then it's an original nsutil.dll.
3) Get the properties of the input audio.
4) If (it's a float32, and nsutil_mod_InputIsFloat32 is not NULL) then call nsutil_mod_InputIsFloat32(1) and send float32 input data to the encoder.
5) Otherwise convert float32 to int32 and send it to the encoder.

[ Of course Winamp cannot use this version of nsutil.dll! ]

Also I don't know the best way to load this .dll:
a) LoadLibrary("enc_fhgaac.dll"); GetModuleHandle("nsutil.dll");
b) LoadLibrary("nsutil.dll"); LoadLibrary("enc_fhgaac.dll");
c) LoadLibrary("nsutil.dll"); LoadLibrary("enc_fhgaac.dll"); FreeLibrary("nsutil.dll"); GetModuleHandle("nsutil.dll");

This post has been edited by lvqcl: May 17 2015, 00:59
Go to the top of the page
+Quote Post
Case
post Apr 24 2015, 21:33
Post #8





Group: Developer (Donating)
Posts: 2436
Joined: 19-October 01
From: Finland
Member No.: 322



I got stuck while test converting the first float file. After 32 seconds of processing encoder->Encode starts to return zero length output and processing no longer advances. The replacement nsutil.dll works fine if nsutil_mod_InputIsFloat32 is never called with true flag. I'll attach the current sources if you wish to take a look. Attached File  fhgaacenc.zip ( 18.94K ) Number of downloads: 31
Go to the top of the page
+Quote Post
lvqcl
post Apr 25 2015, 00:57
Post #9





Group: Developer
Posts: 3730
Joined: 2-December 07
Member No.: 49183



Unfortunately I cannot reproduce it. sad.gif
Go to the top of the page
+Quote Post
Case
post Apr 25 2015, 09:26
Post #10





Group: Developer (Donating)
Posts: 2436
Joined: 19-October 01
From: Finland
Member No.: 322



Here's the test file I used. I intentionally scaled it into clipping to better test the encoder's abilities with float input. Attached File  test_track.wv ( 10.73MB ) Number of downloads: 33
Go to the top of the page
+Quote Post
nu774
post Apr 25 2015, 10:28
Post #11





Group: Developer
Posts: 660
Joined: 22-November 10
From: Japan
Member No.: 85902



QUOTE (Case @ Apr 25 2015, 17:26) *
Here's the test file I used. I intentionally scaled it into clipping to better test the encoder's abilities with float input. Attached File  test_track.wv ( 10.73MB ) Number of downloads: 33

Maybe the encoder cannot handle too loud input.
Encoding went fine by adjusting gain of that file by -2dB.
Go to the top of the page
+Quote Post
lvqcl
post Apr 25 2015, 12:59
Post #12





Group: Developer
Posts: 3730
Joined: 2-December 07
Member No.: 49183



I tested the encoder with a track with audio data multiplied by 2 (+6dB). All was fine and I didn't thought there's a limit. In test_track.wv I can see +20 dBFS values (10x multiply).

For sine and square wav files: the encoder stops when the amplitude exceeds ~18 dBFS (Sample value exceeds "262144"?)

It seems that it is necessary to limit floating point input by +/-8.0 values (=18.06 dBFS).

This post has been edited by lvqcl: Apr 26 2015, 01:21
Go to the top of the page
+Quote Post
Case
post Apr 25 2015, 14:51
Post #13





Group: Developer (Donating)
Posts: 2436
Joined: 19-October 01
From: Finland
Member No.: 322



Lovely. Didn't think of testing with a quieter signal. Here's a compiled version together with float-enabled nsutil.dll if people without compiler want to try: Attached File  fhgaacenc.zip ( 112K ) Number of downloads: 73


And sources (including nsutil): Attached File  fhgaacenc-20120624_-_2015-04-25.zip ( 20.22K ) Number of downloads: 58

Go to the top of the page
+Quote Post
eahm
post Apr 26 2015, 19:29
Post #14





Group: Members
Posts: 1323
Joined: 11-February 12
Member No.: 97076



Will this new make it in the Free Encoder Pack or for some reasons it shouldn't? It is just a test or a stable thing?

Second question, with this version we should enable/change the "Highest BPS" on foobar2000 to 32 right? Any other AAC supports 32? Not that I care (I don't even care about 24 telling the truth) but I want to set the correct settings when I update the CLI version.

Thanks.

This post has been edited by eahm: Apr 26 2015, 19:30
Go to the top of the page
+Quote Post
Case
post Apr 27 2015, 08:21
Post #15





Group: Developer (Donating)
Posts: 2436
Joined: 19-October 01
From: Finland
Member No.: 322



My intention is to put this in the next Free Encoder Pack. It should be stable but more people testing it with varying material would help proving this.

The change enabled by lvqcl's modified dll will not have any benefit unless the Converter is set to output 32-bit float. Neroaacenc and qaac support float and the encoders can make full use of it. Fdkaacenc allows float input but the FDK encoder doesn't support it. The frontend compresses the clipping peaks to allowed scale.

I think you should care. You can freely use any DSPs or input format and won't have to worry about clipping ruining the encoding. Even if encoded file would turn out too loud and playing it without ReplayGain or SoundCheck sounds bad, you can fix it with foobar2000's ReplayGain scanner by applying the gain change to the file permanently.
Go to the top of the page
+Quote Post
eahm
post Apr 27 2015, 08:40
Post #16





Group: Members
Posts: 1323
Joined: 11-February 12
Member No.: 97076



Oh nice, thanks for the explanation, I will do more research. I saw a video once that explained why we should only care about 32 for production other than 24 but I'm not sure I followed and I'm not even sure how expert the guy was.

Talking about foobar2000's Converter settings, FhG is set to 24 but FDK, QAAC and Nero to 32. If FDK something that needs to be changed?

This post has been edited by eahm: Apr 27 2015, 08:41
Go to the top of the page
+Quote Post
lvqcl
post Apr 27 2015, 17:00
Post #17





Group: Developer
Posts: 3730
Joined: 2-December 07
Member No.: 49183



I noticed that fhgaacenc with standard nsutil.dll encodes 8-bit WAV files incorrectly: the amplitude is halved. The modified nsutil.dll doesn't have this issue.

(of course fhgaacenc can convert 8-bit input to 16-bit before sending it to the encoder; in this case it will always work correctly)
Go to the top of the page
+Quote Post
Case
post May 1 2015, 20:18
Post #18





Group: Developer (Donating)
Posts: 2436
Joined: 19-October 01
From: Finland
Member No.: 322



While testing the 8-bit issue I noticed gapless handling bug with non-piped input. I fixed these and did some other minor enhancements.
New binary: Attached File  fhgaacenc.zip ( 78.78K ) Number of downloads: 119
Sources: Attached File  fhgaacenc-20120624_-_2015-05-01.zip ( 20.9K ) Number of downloads: 60

Go to the top of the page
+Quote Post
sluggy
post May 3 2015, 17:55
Post #19





Group: Members
Posts: 81
Joined: 22-June 12
Member No.: 100900



QUOTE (Case @ May 1 2015, 20:18) *
While testing the 8-bit issue I noticed gapless handling bug with non-piped input. I fixed these and did some other minor enhancements.
New binary: Attached File  fhgaacenc.zip ( 78.78K ) Number of downloads: 119
Sources: Attached File  fhgaacenc-20120624_-_2015-05-01.zip ( 20.9K ) Number of downloads: 60


Thanks for the update guys! Im happy to see people still improving this great encoder smile.gif

ps. I only found this thread by looking on the off-chance, It may be better to share this in the aac section.
Go to the top of the page
+Quote Post
sluggy
post May 13 2015, 11:04
Post #20





Group: Members
Posts: 81
Joined: 22-June 12
Member No.: 100900



QUOTE (Case @ Apr 27 2015, 08:21) *
My intention is to put this in the next Free Encoder Pack. It should be stable but more people testing it with varying material would help proving this.

The change enabled by lvqcl's modified dll will not have any benefit unless the Converter is set to output 32-bit float. Neroaacenc and qaac support float and the encoders can make full use of it. Fdkaacenc allows float input but the FDK encoder doesn't support it. The frontend compresses the clipping peaks to allowed scale.

I think you should care. You can freely use any DSPs or input format and won't have to worry about clipping ruining the encoding. Even if encoded file would turn out too loud and playing it without ReplayGain or SoundCheck sounds bad, you can fix it with foobar2000's ReplayGain scanner by applying the gain change to the file permanently.


Is there any way to tell if encoded files are encoded using 32bit float?
Go to the top of the page
+Quote Post
yetanotherid
post May 16 2015, 23:53
Post #21





Group: Members
Posts: 39
Joined: 11-August 08
Member No.: 56966



QUOTE (sluggy @ May 13 2015, 20:04) *
Is there any way to tell if encoded files are encoded using 32bit float?


By sending the encoder audio with peaks above 0dB. If they're clipped the input isn't 32 bit float.
You can test by scanning the encoded file with ReplayGain (track gain). If the reported peak is at maximum (a value of 1) and you increase the input level and encode again, the reported peak should be greater than 1 if 32 bit float is used. If it's not, the peaks are being clipped.

ReplayGain might report a value slightly higher than 1 even when the peaks are exactly at 1, due to the way lossy audio is decoded, but if you take a wave file that you know has a peak of 0db and re-encode it with an encoder that accepts 32 bit float while increasing the volume by 6db, when you scan the encoded file with ReplayGain it should report a peak of around 2, I think. If the peak still isn't much higher than 1, then no doubt it was clipped and therefore the input wasn't 32 bit float (or the encoder downsampled it first).

This post has been edited by yetanotherid: May 16 2015, 23:57
Go to the top of the page
+Quote Post
yetanotherid
post May 17 2015, 00:27
Post #22





Group: Members
Posts: 39
Joined: 11-August 08
Member No.: 56966



I downloaded the zip file from post #18, replaced fhgaacenc.exe and nsutil.dll, then used the method from my previous post to check and 32 bit float input seems to be working fine.

Thanks!
Go to the top of the page
+Quote Post
sluggy
post May 17 2015, 10:31
Post #23





Group: Members
Posts: 81
Joined: 22-June 12
Member No.: 100900



QUOTE (yetanotherid @ May 16 2015, 23:53) *
QUOTE (sluggy @ May 13 2015, 20:04) *
Is there any way to tell if encoded files are encoded using 32bit float?


By sending the encoder audio with peaks above 0dB. If they're clipped the input isn't 32 bit float.
You can test by scanning the encoded file with ReplayGain (track gain). If the reported peak is at maximum (a value of 1) and you increase the input level and encode again, the reported peak should be greater than 1 if 32 bit float is used. If it's not, the peaks are being clipped.

ReplayGain might report a value slightly higher than 1 even when the peaks are exactly at 1, due to the way lossy audio is decoded, but if you take a wave file that you know has a peak of 0db and re-encode it with an encoder that accepts 32 bit float while increasing the volume by 6db, when you scan the encoded file with ReplayGain it should report a peak of around 2, I think. If the peak still isn't much higher than 1, then no doubt it was clipped and therefore the input wasn't 32 bit float (or the encoder downsampled it first).


Great. Thankyou for the reply. I will make sure i use 32bit float from now on.
Go to the top of the page
+Quote Post
eahm
post Jun 2 2015, 16:48
Post #24





Group: Members
Posts: 1323
Joined: 11-February 12
Member No.: 97076



Is this latest fhgaacenc version (post #18) included in Free Encoder Pack 06-02?

Yes it is, just did an hash check. Thank and sorry for asking before double checking.

This post has been edited by eahm: Jun 2 2015, 17:41
Go to the top of the page
+Quote Post
sluggy
post Aug 28 2015, 19:36
Post #25





Group: Members
Posts: 81
Joined: 22-June 12
Member No.: 100900



Since using this updated fhgaacenc i get random errors upon completion in fb2k and dbpoweramp, I think the error from dbpoweramp said failed to encode from pipe, if i encode an album with say 10 songs it may only happen on 1 song. Has anyone else noticed this? Is there anyway to find out exactly what it would be in fb2k?
Go to the top of the page
+Quote Post

2 Pages V   1 2 >
Reply to this topicStart new topic
2 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
1 Members: sluggy

 



RSS Lo-Fi Version Time is now: 1st September 2015 - 13:16