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 856473 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

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

Reply #1200 –
Thanx for your time, I really appreciate it. Normalizing the tracks seems to create no difference other than that the glitch just sounds slightly different. I don't think it's related to clipping (I still might be wrong) since many of those gaps/glitches are not on samples that clip, if not all of them.
For example, on the "All My Love" file I sent, the glitch is on a spot with another like 4db headroom spare. It feels as if it crates a corrupted block/frame. Also my guess is that if it was a clipping issue. if I'd cut a 30 second sample of the problematic spot, it would create the same glitch, but instead it sounds fine. Hmmm...

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

Reply #1201 –
Quote from: Case on
You have things backwards. The floating point support allows the encoder to accept signals that go beyond digital fullscale without clipping. And such files can be played back attenuated and fully prevent all clipping. FDK on the other hand would hard clip the signal before even touching it and the clipping damage would be permanent.

It's all good my friend. English is not my primary language so I probably wrote something misleading.

qaac, having a 32-bit float input, will accept clipping files (everything above 0db) happily, and they will show up in Audacity in solid red.

FDK on the other hand, will hard clip like you said, but if you open the files in Audacity they will appear completely normal.
I should of have said heavy instead of hard clipping. Ehh my bad, my apologies :)

Loudness normalization was more like general advice to Klimis but anyway, like we said earlier.

Quote from: Markuza97 on
I am not saying that clipping is the problem, but you should check it out first.
Quote from: Case on
Also the signal being loud is not related to the weird gaps in the tracks.

We can't tell you Klimis anything useful releated to your problem before you send us the source files.
gold plated toslink fan

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

Reply #1202 –
Quote from: Markuza97 on
We can't tell you Klimis anything useful releated to your problem before you send us the source files.
I updated the link to include the disc rips in flac.

Mind you that it's not even hard for me to stumble upon a track that gets these glitches, it's just that there's some tracks it goes REALLY bad, way worse than my examples.

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

Reply #1203 –
"Aeterna" and "All My Love" samples have bitrate starvation.
At 64 kbit/s encoder will, how can I say this, "pay less atention" and the problems will be less audible.
At 80 kbit/s that you were using, encoder will try to preserve details but it will fail because of low bitrate.
"Aeterna" needs 96 kbit/s to sound acceptable.
"All My Love" needs 112 kbit/s to sound acceptable.
I would say that these two samples are nothing special, just bitrate starvation.
You should be using 192 kbit/s with AAC for transparency anyway.

But "Feelslikeimfallinginlove" is very interesting.
My own encode sounds fine but your file has literally a hole in it.
You said it is not hard for you to stumble upon a track that gets these glitches.
Are you sure that your HDD/SSD is not dying?

Top is yours, bottom is mine. Same encoding parameters.

gold plated toslink fan

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

Reply #1204 –
Thanks, now the problem is reproducible. Your shared encodes for some reason don't match the original file durations like they should and like my encodes do, so my initial assumption was that some DSP messes things up.
But my encodes have all the same glitches. I wanted to verify if bypassing qaac and using iTunes alone behaves the same, but I seem to be too stupid for Apple software. No matter where I have the wav and import it into iTunes library, clicking Convert gives an error that file can't be found. Which is funny because the player can play it and Process Monitor shows zero errors from iTunes attempting to access it...
At this point all I can say is that you really should avoid CBR mode. Apple themselves don't recommend it, or only recommend it when network conditions absolutely require it. And I believe it has never been used in any listening tests where Apple encoder's quality has proven itself. They are always done in VBR mode, which gives the smallest size with best quality.
Your test samples sound better and turn out smaller when encoded with VBR Q36. If you fear VBR for some reason, the ABR mode can also be used to avoid these glitches. I really don't think it's qaac bug. Not sure it's a bug in Apple's encoder either- could simply be that there are no bits left to encode anything and no on has bothered to improve CBR quality as its use makes no sense.

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

Reply #1205 –
I could reproduce it and see the "hole" on CoreAudioToolbox 7.9.8.x and 7.9.10.x.
It doesn't happen on CoreAudioToolbox 7.9.7.x (file attached), but I only checked at 0m25s of "Aeterna" sample. So, it may happen on different spots...
Apparently it's an issue on the encoder side, probably unnoticed because nobody uses CBR.
IIRC, iTunes doesn't support CBR mode (only ABR or CVBR).

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

Reply #1206 –
None of the tracks seem to get these glitches with the old dll.

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

Reply #1207 –
Quote from: nu774 on
I could reproduce it and see the "hole" on CoreAudioToolbox 7.9.8.x and 7.9.10.x.
It doesn't happen on CoreAudioToolbox 7.9.7.x (file attached), but I only checked at 0m25s of "Aeterna" sample. So, it may happen on different spots...
Apparently it's an issue on the encoder side, probably unnoticed because nobody uses CBR.
IIRC, iTunes doesn't support CBR mode (only ABR or CVBR).
hi
may i know the last itunes version  with CoreAudioToolbox 7.9.7.x ?
i don't think i could just replace the file uploaded with the last itune version
thanks

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

Reply #1208 –
Judging from the DLL’s timestamp, it's probably 10.6.x or before.

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

Reply #1209 –
Thank you for looking into this issue everyone, I really appreciate it. I'm glad to see that I don't remember incorrectly, it was indeed fine at some point and it just broke. I don't use all that much these specific settings that are on the files I shared with you, it was merely an example that "accentuates" the issue so it can be more easy to hear/see. I know how bit starvation sounds and I didn't expect any different results but I found it so weird that it was always that specific point in the track nomatter what bitrate I encode it on UNTIL, I edit the fle in some way that alters it's length. So it's not really typical bit starvation, but atleast more than one thing broken in the chain.

I found it so weird because FDK and FhG were creating exactly the results I expected them to create. I'm starting to have trust issues with qAAC at this point, I may roll back to a previous CoreAudioToolbox version.

Well atleast I'm happy that *atleast for the time being* if somebody wants to use the current version in the problematic settings on my example, you have an example of why they should not do it, atleast not until there's a solution to it or roll back to a previous version.

Also maybe https://wiki.hydrogenaud.io/index.php?title=AAC_encoders AAC's CBR should be changed from "Yes" to "Buggy" with a link to why? Would that be a good suggestion?

PS: I feel like I've just opened a huge can of worms. (nervous)

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

Reply #1211 –
I've tried running afconvert from github actions and it seems unaffected.
github runnner image: macos-14-arm64
OS version: macOS 14.7.2 23H311

I have an impression that Apple has long abandoned updating Windows port of CoreAudio components, and the issue is only fixed on the Mac OS side.

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

Reply #1212 –
The question is since 2012, how many substancial quality changes have been done? It's a pretty long time to even consider a rollback as a good option.

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

Reply #1213 –
The AAC codec is supposed to have changed a couple of times in the sense that they produce non-identical bitstreams, but I doubt that there was any meaningful quality improvement since 2012.

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

Reply #1214 –
Quote from: nu774 on
The AAC codec is supposed to have changed a couple of times in the sense that they produce non-identical bitstreams, but I doubt that there was any meaningful quality improvement since 2012.

That actually sounds like a good incentive for me (or anybody that may be interested) to start a listening test between 2012 and current versions. What's your thoughts on this?

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

Reply #1216 –
Quote from: nu774 on
Well, I see no reason to object. 7.10.9.10 came out at 2017, and since then it's not updated.

Some tests in the past:

7.10.9.10
https://hydrogenaud.io/index.php/topic,120062.0.html

7.9.8.5
https://listening-test.coresv.net/index.htm

7.9.7.9
https://hydrogenaud.io/index.php/topic,97913.0.html
hi
so we need to download the last version of itunes and extract the files and replace only  CoreAudioToolbox  ,just because the new are buggy
do i need visual c++ 2019?
thanks

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

Reply #1217 –
Quote from: francesco on
Quote from: nu774 on
Well, I see no reason to object. 7.10.9.10 came out at 2017, and since then it's not updated.

Some tests in the past:

7.10.9.10
https://hydrogenaud.io/index.php/topic,120062.0.html

7.9.8.5
https://listening-test.coresv.net/index.htm

7.9.7.9
https://hydrogenaud.io/index.php/topic,97913.0.html
so we need to download the last version of itunes and extract the files and replace only  CoreAudioToolbox
IDK, do you really use cbr mode? Otherwise no call for action.

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

Reply #1218 –
I am starting to wonder if Apple could make their AAC Encoder open source.

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

Reply #1219 –
Quote from: nu774 on
I could reproduce it and see the "hole" on CoreAudioToolbox 7.9.8.x and 7.9.10.x.
It doesn't happen on CoreAudioToolbox 7.9.7.x (file attached), but I only checked at 0m25s of "Aeterna" sample. So, it may happen on different spots...
Apparently it's an issue on the encoder side, probably unnoticed because nobody uses CBR.
IIRC, iTunes doesn't support CBR mode (only ABR or CVBR).
Do I need an older/different version of qaac?
Both qaac and qaac64 return a [ERROR: 193: CoreAudioToolbox.dll] when I try --check on them.

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

Reply #1220 –
Hello, dear people. I am glad that I found your forum and I hope that you will be able to help me.
I have FLAC music that I want to successfully convert to high-quality AAC. I followed many instructions, but none of them worked.
I downloaded Foobar2000 and downloaded the audio codecs from their site.
Then I put the files in one folder: makeportable.cmd, iTunes64Setup, qaac. All of them is the latest version. They are all version 64, I followed the instructions, names and everything else. After I start makeportable, it just flashes and closes immediately. It does not generate anything. I downloaded different versions of qaac, there is no difference. And Foobar gives the following error: "An error occurred while writing to file (The encoder has terminated prematurely with code 2 (0x00000002); please re-check parameters) ... Conversion failed: The encoder has terminated prematurely with code 2 (0x00000002); please re-check parameters".
I have been trying to solve this problem for several days and I can't. I am using Windows 10 Home, 64-bit operating system, x64-based processor. Please help.

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

Reply #1221 –
Welcome. You need 'makeportable2.cmd'.

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

Reply #1223 –
And don't give up. As mentioned in https://github.com/nu774/qaac/wiki/Installation you can open the installer with a packer like 7-zip and just drag out a few dlls and exe (if something goes wrong with makeportable). You do it once and never again.

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

Reply #1224 –
You are amazing; I'm not installing 7zip; that is the problem. I appreciate your help.