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: QAAC: discussion, questions, feature requests, etc. (Read 687489 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: QAAC: discussion, questions, feature requests, etc.

Reply #1175 –
qtfiles(64), iTunes directory and Apple Application Support directory are prepended to PATH environment variable (in this order) in qaac process.
Other than that, DLL search order of qaac is pretty normal and like this:

  • Same folder as qaac64.exe (or qaac.exe).
  • Windows System32 (or SysWOW64) directory.
  • Windows directory.
  • qtfiles64(or qtfiles) directory next to qaac64.exe(or qaac.exe)
  • iTunes install directory specified in registry
  • Apple Application Support install directory specified in registry
  • Directories in PATH environment variable

Re: QAAC: discussion, questions, feature requests, etc.

Reply #1176 –
@for the developer

Hi,
i have a problem wich randomly happens to me with wich now i'm banging my head on, trying to solve (unsuccesfully).

I have an audio file wav (or flac no matter) 5.1 of lentgh 1:04:49.456.

When i compress with QAAC no matter what the options, i end up with a "pop / click" in the last part of the audio.
Opening in Audition i end up with a file of 1:04:49.485.
I've tried with a lenght of 1:04:49.478 and i end up again with a 1:04:49.485 (with pop click)

I'm pretty sure it's some problem regarding the length of the last audio frame.

Could you suggest me (while you analyze the problem) the right audio lenght to not make the "pop / clck" appear?

Here's the spectrum.

What's the problem?



Temporary Solution

Ok, as i was hypothizing it had to be a low level problem.
I remembered reading around in the discussion that QAAC uses a frame size of 1024,
so i thought that pheraps something in this particular file (remember the problem happens randomly)
was connected with the frame size that was giving problem with the encoding.

So, with delaycut i got the number of frames in the audio wav

186693888

I dived by 1024 and i got not an exact number (ha ha!).

186693888 / 1024  = 182318,25

With delaycut i calculated the exact frame count to give me an exact division

182319 * 1024 =    186694656

So my file had be of length of 186694656

The number of delay in delaycut that gave me that frame count was -16 ms

So i added -16ms to the wav, compress it with QAAC and voilà. No pop at the end.

So, having said so, could you implement a check and an (optional) autofixing to avoid the problem?
You could emit a warning before continuing encoding and an option to auto fix frame count
with anticipation or delaying.

Re: QAAC: discussion, questions, feature requests, etc.

Reply #1177 –
See here: https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html

From testing that I did, admittedly some time ago, it was apparent that most decoders do not cut the padding at the end of the aac data. The old Nero decoder was one that did perform correctly, from what I remember.

Re: QAAC: discussion, questions, feature requests, etc.

Reply #1178 –
Because of i cannot edit the post i give here the edit

Quote
So i added -16ms to the end of wav

Quote
an option to auto fix frame count
with adding or cutting at the end of file

@john33
Interesting informations thank you.

Re: QAAC: discussion, questions, feature requests, etc.

Reply #1179 –
I have a 96 KHz file which I'm looking to preserve in this sample rate.  I am using the QAAC encoder in Foobar2000 and the only parameter it has to set is the bitrate/quality which I have set to Q91 (~192 kbps).  The resulting file ends up 48 KHz.  I don't imagine this is a limitation of the encoder and I know it isn't of the codec.  Can anyone help with what the issue might be and how to possibly correct this?

Thanks in advance!

Re: QAAC: discussion, questions, feature requests, etc.

Reply #1180 –
For a long time I use qaac with Foobar2000.
From some time, when coding is classical music, especially old, 1950-1970s, as well as solo performers in Foobar2000 version2 with the latest versions of qaac I get an unexpectedly low bitrate.
qaac 8.20 with parameters -a 224 or -v 256 I get files with a bitraite not higher than 190. Although -c, -cbr works quite adequately.
What can I do with it?

Re: QAAC: discussion, questions, feature requests, etc.

Reply #1181 –
Hi. Is QAAC's TVBR mode deterministic? The reason I ask is because I don't get consistent output. In my testing, encoding a source file multiple times using the same settings outputs one of several variants. In one test I encoded a source file 20 times and the resulting 20 encodes were comprised of four variants: 7 were variant A, 6 variant B, 3 variant C, and 4 variant D. Here's an example of Foobar2k's bit-compare:
Code: [Select]
Differences found in compared tracks.
Zero offset detected.

Comparing:
"S:\varA.m4a"
"S:\varB.m4a"
Compared 69880860 samples.
Differences found: 2304 values, 14:25.880816 - 19:46.173946, peak: 0.005567 (-45.09 dBTP) at 14:25.882857, 1ch
As you can see, the difference is rather quiet. I certainly can't hear anything, but I was surprised the results were different at all. In contrast, encoding with LAME, Opus, or Vorbis yields identical output every time. So does QAAC using CVBR.

In my research before making this post I discovered someone probably encountered the same thing over six years ago. lordmulder's responses were thoughtful and informative but there wasn't really a conclusive answer.

Re: QAAC: discussion, questions, feature requests, etc.

Reply #1182 –
It's far too late to edit the above post, but I've finally had more time to test and I need to make a correction and add an apparent conclusion.

First, I had thought CVBR mode generated consistent results and it was only TVBR that didn't, but further testing has revealed that's not necessarily the case. In fact, I found a file for which all modes generate inconsistent, multiple-variant output.

That discovery prompted me to install iTunes (which as far as I recalled has only CVBR and ABR modes) in a VM and test it directly instead of using QAAC. Both modes showed the same inconsistent behavior with this particular file.

So, ultimately, the seemingly odd behavior I encountered just appears to be how Apple's encoder works. I still can't shake the feeling that it's a bit weird, especially considering how other encoders are totally consistent. but it is what it is.

 

Re: QAAC: discussion, questions, feature requests, etc.

Reply #1183 –
Quote from: gib on
It's far too late to edit the above post, but I've finally had more time to test and I need to make a correction and add an apparent conclusion.

First, I had thought CVBR mode generated consistent results and it was only TVBR that didn't, but further testing has revealed that's not necessarily the case. In fact, I found a file for which all modes generate inconsistent, multiple-variant output.

That discovery prompted me to install iTunes (which as far as I recalled has only CVBR and ABR modes) in a VM and test it directly instead of using QAAC. Both modes showed the same inconsistent behavior with this particular file.

So, ultimately, the seemingly odd behavior I encountered just appears to be how Apple's encoder works. I still can't shake the feeling that it's a bit weird, especially considering how other encoders are totally consistent. but it is what it is.



May be related, but have you ever tested different versions of CoreAudioToolbox? I'm wondering if there was a past version that had a better encoder than the present 7.10.9.0