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

QAAC: discussion, questions, feature requests, etc.

Reply #725
@nu774:
I'd like to suggest a new feature for qaac, which (I think...) would be quite easy to implement:

  >> Allow playlist files (.m3u) as input for qaac.

This could come in very handy if you encode a complete album or your favourite playlist.
Or, in my case, encoding an audiobook and concat it to a single m4b file. In that scenario, my NAS sometimes lists files in random order when running "dir *.flac". Which would result in an audiobook with random chapters when i use "*.flac" as input arg for qaac...

Or could I use (in that particular case) this option:
Code: [Select]
--sort-args            Sort filenames given by command line arguments.

How could that be used to force qaac to sort all files matching a wildcard input file argument by e.g. filename in ascending order?

.sundance.

QAAC: discussion, questions, feature requests, etc.

Reply #726
Or could I use (in that particular case) this option:
Code: [Select]
--sort-args            Sort filenames given by command line arguments.

How could that be used to force qaac to sort all files matching a wildcard input file argument by e.g. filename in ascending order?

As is written in the message, --sort-args will sort the filenames given by the command line.
The result will be ordered in ascending order, and the process (encoding) is done in this order.
So, if you name files like "01 foo.flac", "02 bar.flac"... , it will work as you intended.

This option was introduced by a request which was exactly the same as yours.

QAAC: discussion, questions, feature requests, etc.

Reply #727
Thanks for explanation.
I did search this thread before posting but didn't find anything for "sorting" and "filenames".

I was thinking that I needed additional parameters for the "--sort-args" option to specify the sort options...

.sundance.

QAAC: discussion, questions, feature requests, etc.

Reply #728
So, well, thank you very much for the surprisingly quick implementation of AviSynth support. It will help those who create movie backups with e.g. AVC+AAC in MP4 containers. 

QAAC: discussion, questions, feature requests, etc.

Reply #729
I just noticed a problem with QAAC's limiter option. I decoded the 5.1ch AC3 track of David Bowie's Glass Spider concert (DVD) to a 32-bit float wav with eac3to and ran qaac.exe -V 91 --verbose --no-delay --limiter -o "xxx.m4a" "xxx.wav". eac3to had already noticed that there was clipping and thus had adjusted the volume accordingly. I checked the peak with qaac and it showed 0.99.

I started wondering why the encoding took so long (estimated to take almost 30 minutes) and looked at the Task Manager. The qaac.exe process was consuming one CPU at maximum but the i/o throughput was very small. When I dropped the limiter parameter, the encoding processed normally.

Hope this helps in finding something out, I can also provide a small sample file if needed.

QAAC: discussion, questions, feature requests, etc.

Reply #730
Hope this helps in finding something out, I can also provide a small sample file if needed.

Usually --limiter is not that slow.
Please provide a sample that reproduces the issue.

QAAC: discussion, questions, feature requests, etc.

Reply #731
Wondering if anyone could help me.  I use a program called LPRipper to cut up and label recorded vinyl tracks.  It has a built in encoder option that allows the use of command line encoders.  I have been using the Nero encoder but would like to try the QAAC encoder.  But struggling to understand the command lines for this program.  I want to be able to bulk encode files using the same file name in the same folder but encode from WAV to M4A with high quality, 192-256 VBR.  Can't seem to get the infile and outfile commands right.  Can anyone recommend a sample command line that I might try?

Also, is there a requirement that certain of the files need to be in the same folder as the qaac.exe?  Does QAAC automatically find the Apple files or do they need to be there?

Using Windows7 and Windows8 64bit.

QAAC: discussion, questions, feature requests, etc.

Reply #732
@nu774, you probably aren't interested in a 13 year old obsolete OS but i'm stuck running windows xp. qaac itself works fine but i notice your makeportable batch file checks for 7-zip by looking under the HKCU registry key. on my system, it's actually located under HKLM. obviously i've got it running by myself but i just thought i'd mention it.... 

QAAC: discussion, questions, feature requests, etc.

Reply #733
Can anyone recommend a sample command line that I might try?

If you really want an average bitrate of ~224 kbps (which is probably overkill), try:

Code: [Select]
for %1 in (*.wav) do qaac.exe -v 224 %1 %1.m4a



Also, is there a requirement that certain of the files need to be in the same folder as the qaac.exe?  Does QAAC automatically find the Apple files or do they need to be there?

The "QTfiles" folder should be in the same folder as qaac.exe. Unless qaac.exe is in a folder included in the system's PATH variable, you need to cd into that folder before you can run the qaac command.

QAAC: discussion, questions, feature requests, etc.

Reply #734
@ freddy687:

Regarding the last point: If QuickTime or even iTunes is installed, then the required Apple CoreAudioToolBox DLLs will be in a directory which is added to the PATH so they can be found whereever they are installed.

If you don't like Apple software to be installed, and you prefer to extract the DLLs out of QuickTime or iTunes installers using makeportable.cmd, then they have to be put together with qaac.exe to ensure that they are available specifically for QAAC, no other application will need them anywhere else in this case.

You may use a bitrate for QAAC, but it is not recommended, best quality will be achieved in "True VBR" mode. I would suggest to use parameters like:

--tvbr 81 --threading -o outfile.m4a infile.wav (for M4A output with True VBR quality mode, quality level 81 – there are some common values for discrete steps, like: 72, 81, 90)
--abr % --adts --threading -o outfile.aac infile.wav (for ADTS AAC output with ABR mode, using the maximum bitrate from the slider in LP Ripper options)

^ untested. Try and report either version in different combinations.

QAAC: discussion, questions, feature requests, etc.

Reply #735
@nu774, you probably aren't interested in a 13 year old obsolete OS but i'm stuck running windows xp. qaac itself works fine but i notice your makeportable batch file checks for 7-zip by looking under the HKCU registry key. on my system, it's actually located under HKLM. obviously i've got it running by myself but i just thought i'd mention it.... 

Thanks, updated to HKLM.

QAAC: discussion, questions, feature requests, etc.

Reply #736
qaac can't use libsoxconvolver64.dll for lowpass, only the 32 bit version. Why is this?

QAAC: discussion, questions, feature requests, etc.

Reply #737
qaac can't use libsoxconvolver64.dll for lowpass, only the 32 bit version. Why is this?

When you donwload qaac you can see two folders inside the archive, x86 and x64. There is not qaac.exe inside the x64, is it too hard to understand qaac.exe is only 32-bit?

QAAC: discussion, questions, feature requests, etc.

Reply #738
Question on the "-r keep" switch.
I have tried the "-r keep" switch and seen that it works in the following way:
Input        Output
44.1        44.1
48            48
88.2        48
96            48
176.4      48
192          48

I know that from a sound quality point of view it probably does not make any difference, but would it be possible to change the behavior so that the division of sample rate is an integer?
Input        Output
44.1        44.1
48            48
88.2        44.1
96            48
176.4      44.1
192          48

QAAC: discussion, questions, feature requests, etc.

Reply #739
I know that from a sound quality point of view it probably does not make any difference, but would it be possible to change the behavior so that the division of sample rate is an integer?

When the input rate is 64kHz (which is not supported), what do you want? 32kHz?
If you stick to integer division for some magical reason, yes you have to pick 32kHz in this case, instead of 48kHz. However, I don't think it's a good choice. Do you?

Current behavior of qaac is quite simple. It just picks the nearest value that is supported by the encoder. And I want keep it simple.
If you want to resample to specific rate for your needs, you can simply use --rate=44100 or something.

QAAC: discussion, questions, feature requests, etc.

Reply #740
Hi nu774. Not meaning to be a pain, apologies if I have. qaac is simply the best and easiest way to convert to aac, that's why I use it.
My question only concerns the bitrates which are multiples of 44.1 or 48. For everything else the behavior is fine as it is (using 48 for anything >48 I guess).
In my view integer transformation is simpler than non integer, less processor intensive. I simply like the "efficiency" of the integer division vs. the non integer one.
If this adaptation is not easily possible, I am sure I can find a way to detect the input sample rate before the conversion and set the -r parameter (which is what I have done manually in the past, but I would like to automate the process).

QAAC: discussion, questions, feature requests, etc.

Reply #741
My question only concerns the bitrates which are multiples of 44.1 or 48. For everything else the behavior is fine as it is (using 48 for anything >48 I guess).

Strictly speaking, your concern looks like only on multiples of 44.1.
I suppose you are ok when multiples of 32/48 result in 48.
Quote
If this adaptation is not easily possible, I am sure I can find a way to detect the input sample rate before the conversion and set the -r parameter

It's possible, in psuedo-code it should look like this:
Code: [Select]
output_rate = UNDEF
for n in 2..MAX:
    if 44100 * n == input_rate:
        output_rate = 44100
        break
if output_rate == UNDEF:
    output_rate = nearest_supported_value(input_rate)

As you can see, you have to treat multiples of 44100 as a "special case".
I just don't think it deserves the special treatment like this.

QAAC: discussion, questions, feature requests, etc.

Reply #742
My question only concerns the bitrates which are multiples of 44.1 or 48. For everything else the behavior is fine as it is (using 48 for anything >48 I guess).
In my view integer transformation is simpler than non integer, less processor intensive. I simply like the "efficiency" of the integer division vs. the non integer one.


Which is your knowledge of resampling algorithms? More so, which is your knowledge of the specific resampler that qaac (in fact Apple's codec) has?

Either your knowledge is limited and think in terms of "rounding" and "cutting" (as if resampling 88.2 to 44.1 consisted only on dropping one of each two samples), or you think in terms of an upsample/filter/decimator combination, and thinking that a 2:1 ratio generates less computations than a 160:147 ratio (but that ignores that such an algorithm, to be efficient, does not generate the samples that it doesn't need, and it might, or might not be the type or resampler used in this case).

So given these facts... can you explain again why do you think it is better to have integer divisions for resampling?

QAAC: discussion, questions, feature requests, etc.

Reply #743
Hi jaz,
I admit to knowing next to nothing about resampling algorithms, except that one cannot cheat maths. More complex algorithms take more processing power, no matter how you slice and dice them. A conversion between two sampling rates that are non integer or closely spaced will need to calculate more complex filters than an integer one (if the same conversion quality is to be achieved).
I have done two conversions and looked at the time needed for the process. Same 88.2kHz FLAC file, once to 48 and once to 44.1 sample rate. The conversion times were 6.9 and 5.9 seconds. Processor load in both cases was around 30% during the conversion.


So it seems to me that there may indeed be a difference in processor load between integer and non integer sample rate conversion of close to 20%. No scientific test, I admit.
Regards
Rudi

QAAC: discussion, questions, feature requests, etc.

Reply #744
More complex algorithms take more processing power, no matter how you slice and dice them.

If you slice and dice any sample rate conversion to only work on a single input:output ratio, it will be faster than the general case. It will also be much less useful. When the algorithm is complex enough, the benefit of a single-ratio optimized case outweigh the cost of maintaining separate versions for each ratio. The algorithm in SoX, for example, is complex enough that I doubt it has separate versions for specific ratios.

A conversion between two sampling rates that are non integer or closely spaced will need to calculate more complex filters than an integer one (if the same conversion quality is to be achieved).

The filters may be more difficult for you to calculate with paper and a pencil, but the computer doesn't know how to take shortcuts unless it's been programmed to do so. (See above.)

I have done two conversions and looked at the time needed for the process. Same 88.2kHz FLAC file, once to 48 and once to 44.1 sample rate. The conversion times were 6.9 and 5.9 seconds. Processor load in both cases was around 30% during the conversion.

Assuming the same input rate and shortcut-free algorithm, the required processing power will be linearly correlated with the output sample rate. A lower output rate means fewer samples need to be calculated, and thus take less CPU time. (Additionally, you may be bound by disk I/O - in which case, a lower output sample rate means less time needs to be spent waiting for the disk.)

No scientific test, I admit.

At least you're willing to admit it.

To make it more scientific, you'd need to run the same test many times and average the results (with a bit of statistical analysis thrown in) to see what kind of differences are typical. You might also try longer/shorter files, to get a good idea of the per-run overhead, or different output sample rates to get a better idea of how speed correlates with output sample rate.

QAAC: discussion, questions, feature requests, etc.

Reply #745
I didn't expect such an important difference, so i did some tests. qaac 2.41, toolbox: 7.9.8.6

88 -> 48 : 11.9x ( 6:12 minutes )
88 -> 44 : 14.5x ( 5:04 minutes )
48 -> 48 : 15.0x ( 4:55 minutes )
44 -> 44 : 15.8x ( 4:40 minutes )

So, there is a difference between resampling and not resampling, there is a difference in the codec working at 44 or 48, and there is a difference in resampling from 88 to 44 compared to 88 to 48.
In the end, it all adds up, but it is true that in this case, the biggest difference comes from the 88 -> 48 resampling.

I did one more test.  Now, using the foobar resampler  (PPHS)

88->48->48 : 14.0x ( 5:17 minutes )
88->44->44 : 15:1x ( 4:57 minutes )

Which is more in line to what I expected.


Soo.......


You are right that when using qaac/apple codec's resampler, it is better to use integer resampling, because the penalty of using non-integer is big.

I am right in saying that resampling to non-integer factors should not have a big penalty.

And in any case, I've demonstrated another thing... It is always faster to use foobar's resampler

QAAC: discussion, questions, feature requests, etc.

Reply #746
I did one more test the other way around. 96kHz file conversion to 48 and 44.1
96 -> 48: 9.64 seconds
96 -> 44.1: 9.59 seconds
This would also support the hypothesis that integer is faster than non integer (if one takes into account that around 8% less samples need to be calculated in the 96 -> 44.1 conversion). This case is much less clear than the other one though.


Given nu774's inputs a few posts back, I think I'll rest my case. I feel my request is too niche and may have unintended side effects that I am not aware of at this time.
Be it as it may, thanks a lot for for your inputs and discussion.

QAAC: discussion, questions, feature requests, etc.

Reply #747
First, qaac can use 3 types of resampler for AAC encoding: soxr, CoreAudio, CoreAudio(codec builtin). When libsoxr (included in qaac distribution) is present, it's chosen by default.

Second, when you do speed comparison of resampler alone, you'd better use -D switch and output to NUL like this:
qaac -D --rate=44100 input.88200.wav -o NUL

Third, as for soxr, it looks like integer ratio down sampling is indeed faster (probably requires smaller numbers of filter stages). Here is the results in my environment:
88200 -> 48000: 117x
88200 -> 44100: 380x
88200 -> 36000: 195x

Finally, If you care about the speed, you can benefit from --threading.
When --threading is on, resampling  runs on the input thread, encoding runs on another thread. Since encoding is a lot slower than input + resampling, encoding speed dominates the whole process, and the total speed shouldn't be affected by the resampling efficiency.

 

QAAC: discussion, questions, feature requests, etc.

Reply #748
Is there any comparison regarding quality between the different options in qaac?

QAAC: discussion, questions, feature requests, etc.

Reply #749
HI !!

Does qaac support downmixing channels to mono dependless on the input channels configuration?

I mean:
convert 5.1 to mono
convert 2.0 to mono
leave mono intact

--matrix-preset mono crashesh for mono files ;(