- It doesn't work!
- What are these x86 and x64 folders? How should I install them?
- How should I setup -b (bits per sample) option?
- How should I setup --rate option?
- With Apple's afconvert command, I can configure quality (-q) 0-127. qaac allows only 0-2. Why?
- Version number of CoreAudioToolbox is different from the one shown in the Windows file property.
- Not getting bit identical result as iTunes/QuickTime
Make sure you have installed AppleApplicationSupport components. In order to check if qaac can see the required libraries, open command prompt and run "qaac --check".
If you have AppleApplicationSupport, it's most likely due to wrong command like you give. Try directly from command prompt and see what qaac says. Note that you need -o to specify output filename. The following is OK:
qaac input.wav -o output.m4a
The following is wrong:
qaac input.wav output.m4a
Since qaac can handle multiple input files, output.m4a is also taken as input file and it fails (since it doesn't exist).
Binaries (dll and exe) inside of x86 are 32bit binaries, and available on both 32bit / 64bit windows.
Binaries inside of x64 are 64bit binaries, and available only on 64bit windows only.
Generally speaking, 64bit exe can only load 64bit dll, and vice versa. Note that MSVC runtime dll(msvcr120.dll and msvcp120.dll) share the same name between 32bit and 64bit version. Although they share the same name they are different, and required by different binaries. Therefore, you cannot overwrite/mix them into the same directory. When both of 32bit and 64bit dll with the same name are placed in some different directories in the PATH, correct one will be picked up by the OS loader.
In case you have installed MSVC runtime in your system, it will be managed and updated via Windows update, and you don't need to copy these MSVC runtime DLLs.
If you are encoding to AAC, there's no such concept of "bits per sample" in the same sense of PCM audio. Therefore, you don't need it (you can use it, but it's simply ignored).
If you are encoding to ALAC losslessly, just don't touch it. Otherwise, use it only when you actually want to change output bit depth. The purpose of this option is to change output bit depth. If you don't touch it (and don't apply any DSP), output bit depth will be the same as input, and this is usually what you want. If you apply some DSP such as sample rate conversion or lowpass filter, internal sample format is converted to float. Therefore, you have to use -b to get 16 or 24bit result.
Usually you don't need it. This is an option to change sample rate, so use it only when you actually want to do sample rate conversion. If you are encoding to AAC, lower sampling rate (or --rate auto) allows you to use more lower bitrate setting.
At API level, CoreAudio allows value in 0-127 for kAudioConverterCodecQuality property. The interface of afconvert command simply reflects it.
However, AAC codec only supports 3 actually functional quality steps (32, 64, and 96), and 0-127 are simply rounded to these values. -q [0-2] of qaac is mapped to 32, 64, or 96, and written into tool tag.
Maybe I should have changed interface of qaac to directly use these actual values. 0-2 has been used just for historical reason. It was more natural way when qaac was based on QuickTime.
These Apple components are internationalized, and contains multiple resources for various locales. However, they have not been updated properly, so inconsistency in the version number under different locales is normal.
While Windows will pick up the resource for the locale windows is currently working in, qaac will always pick the one for en-US locale (English/United States) to avoid this inconsistency. If you want to just see the version number, try qaac --check.
If you are confident that encoder setting such as encoding strategy / bitrate / quality is equivalent, then you have still following possibilities.
- Try --no-smart-padding. qaac by default applies smart padding by extrapolating the beginning/ending of the input, in order to avoid glitches between songs on gapless playback.
- If you are using QuickTime pro, it is known to apply peak limiter, which qaac (and iTunes) doesn't. That has been discussed here: HA forum
- If you are using QuickTime pro, it does not read/write iTunSMPB to support gapless playback. Therefore, even if AAC bitstream is identical, you get zero-padded (longer) output from AAC files encoded by QuickTime when decoded by software capable of gapless playback (such as foobar2000 or iTunes). If you just want to bit-compare AAC bitstream, try demuxing it using ffmpeg or something.
