qtaacenc: a command-line QuickTime AAC encoder for Windows Options

[tedgo]

@punkrockdude
I noticed this too. Also when i encode files in iTunes or with iTunesEncode.
It seems that QuickTime auto-scales the volume down to avoid clipping.

This post has been edited by tedgo: Feb 2 2010, 21:42

[b66pak]

ok...i have done some tests...here are the results...

the qtaacenc encoder accepts wav's up to 32float (mono or stereo ONLY)...

if found that is limited (an old apple flaw!!!) to maximum 186 minutes for a 32float@48000hz wav or 279 minutes for a 24bit@48000hz wav and 327 minutes for a 16bit@48000hz wav!!!

the 4gb limit is on apple side of the encoder...i test it using the STDIN input by feeding a +8hrs .ac3 file with 16, 24, 32, 32float bits...
_

OT: @nao considering your expertise in windows iTunes libraries do you think a CLI raw (or full) mp4 muxer can be done? (.h264 + .acc + softsubs [apple style] + chapters [apple style])

something like subler for mac...

http://code.google.com/p/subler/
_

using iTunes windows libraries instalation...
_

[wkmax]

@punkrockdude
I noticed this too. Also when i encode files in iTunes or with iTunesEncode.
It seems that QuickTime auto-scales the volume down to avoid clipping.

If you are right about QuickTime/iTunes behavior, what about ALAC encoding? (for instance, using iTunes Encode for EAC + iTunes full integration)

[lvqcl]

ALAC never clips.

[wkmax]

ALAC never clips.

Thank you lvqcl, I can sleep peacefully with my ALAC encodings

[greynol]

It seems that QuickTime auto-scales the volume down to avoid clipping.

This is quite trivial to test, so why not test it instead of speculating with words like "seems"???

[tedgo]

What's wrong with the word "seems"?
None of my QuickTime encoded files has a peak above 1.0 and i don't know if QuickTime auto-scales the volume or if its an issue in the encoder...
But since very low volume files aren't effected by this behaviour, i can only guess that its an autoscaling "feature".

This post has been edited by tedgo: Feb 2 2010, 23:31

[lvqcl]

It seems that QuickTime auto-scales the volume down to avoid clipping.

It looks like limiter really. Something like 'advanced limiter' in foobar2000...
It doesn't change input signal if it is less than -0.5 dBFS (approximately!).

This post has been edited by lvqcl: Feb 2 2010, 23:56

[greynol]

I implicitly trust lvqcl, so I won't continue to make an issue out of this except to say one can easily take a loud and likely "clippressed" track that routinely peaks at full-scale, encode and then decode to see if it has a reduction in level.

Maybe it's unrealistic, but I have an expectation that HA members will invest the very short amount of time it takes to test these kinds of things before making statements about what they only think is going on. If this is a matter of having done this in the past and not being certain of the results then I extend my apologies.

This post has been edited by greynol: Feb 3 2010, 00:08

[tedgo]

I implicitly trust lvqcl, so I won't continue to make an issue out of this except to say one can easily take a loud and likely "clippressed" track that routinely peaks at full-scale, encode and then decode to see if it has a reduction in level.

How do you think did i noticed it?
And why don't trust "seems" but "looks like"?
Am I stamped as a liar somehow?

[greynol]

You're over-reacting. I already said I apologize if you had tested this previously.

The thing is that lvqcl gave the impression that he actually conducted a test whereas you did not.

[singaiya]

Quick test:

lame -V 6.248: 126 kbps
lame -V 6.249: 115 kbps

qtaacenc --tvbr 59: 135 kbps
qtaacenc --tvbr 58: 105 kbps

(and qtaacenc --tvbr 58 --samplerate keep: 114 kbps)

I cannot say that 126 is 'much lower' than 135 kbps.

When talking of "much lower" I was thinking of NeroAAC but said mp3 by mistake. The last encoder I used was Nero 1.1.1.3 (I think that's the version before 1.3.3) at ~104 kbps (Q0.25 -LC) and that encoder/setting does not resample to 32 kHz.

Anyway I found a strange behavior with qtaacenc output and iTunes/iPod. Both iTunes and iPod will stop playback at 71.6% through a file. I tested this on three files and they all skipped at different absolute times, but they were each 71.6% of the way through the total time of the file. This behavior does not happen with foobar, but it does both on iTunes 9.0.1.8 and iPod 160 GB version 2.0.2. My command line is --tvbr 59 --highest %s %d.

EDIT: I'm using qtaacenc 20100107. I'll try it with the latest version tomorrow.

This post has been edited by singaiya: Feb 3 2010, 07:11

[lvqcl]

It looks like limiter really. Something like 'advanced limiter' in foobar2000...
It doesn't change input signal if it is less than -0.5 dBFS (approximately!).

I did more test and found the following:

1) Target level is 0.95 (i.e. -0.446 dBFS);
2) Lookahed time is ~5 ms;
3) Attack time is ~ 3 ms;
4) Release time is 11.5 sec (and, gain value raises linearly from 0.95 to 1).

Added: the above values are valid for --normal and --high settings. For --fast: target level = 0.925, release time ~ 17.5 sec.

This post has been edited by lvqcl: Feb 19 2010, 19:22

[singaiya]

Both iTunes and iPod will stop playback at 71.6% through a file.

Update on this: I really don't know what happened with that particular set of three albums I encoded to produce that strange behavior reported earlier. I deleted those QT AAC files and re-encoded from flac, using the exact same method, encoder, and settings, and the files play normally in both iTunes/iPod without skipping to the next song at 71.6% of the current song.

[Xire]

Hi,
Any comments or questions are accepted in this thread.
Thanks

Maybe a bit off-topic, but would it be possible to add alac 24bit encoding to this tool?

This post has been edited by Xire: Feb 4 2010, 13:57

[nao]

Maybe a bit off-topic, but would it be possible to add alac 24bit encoding to this tool?

Possible but I have no plan to implement the feature in this tool.

[rpp3po]

I just realized that nao is 'tmkk', the author of XLD! Creator of one of my most used tools.

If you want to support his work, the XLD page has a donation button.

[kornchild2002]

XLD is a nice tool. I have thought about purchasing a Mac Mini just to use Mac OS X, a couple of other programs, and XLD for QuickTime true VBR AAC encoding. Interesting that someone on the Mac OS X side would finally develop a Windows solution.

Is there anymore insight into the issue with QuickTime/foobar2000 scaling the audio? Is it a setting in foobar2000 or was it an issue with QuickTime (can it be disabled)?

[tedgo]

The scaling has nothing to do with foobar2000, must be on QuickTime's side.
I tried it with converting a near full-scaled file using CVBR in iTunes and TVBR with qtaacenc (directly from command prompt).

CODE

Original WAV file (peak and gain taken from an WavPack encoded from it)
Peak: 0.999908
Gain: -6.61 dB

qtaacenc file (directly encoded from WAV via command prompt, --tvbr 127 --highest)
Peak: 0.968920
Gain: -6.18 dB

iTunes (directly encoded from WAV in iTunes, 320kbps, CVBR)
Peak: 0.969976
Gain: -6.18 dB

Checked with Nero AAC (in foobar2000, Q1.0)
Peak: 1.020406
Gain: -6.60 dB

As you can see, both QT encodings are slightly scaled down.
I would also like to know if this scaling could be disabled...

This post has been edited by tedgo: Feb 4 2010, 23:53

[rpp3po]

Lossy compression adds energy due to filtering artifacts. So scaling down is the right thing to do for ridiculously high peaking tracks as 0.999908 db, else there would be clipping. And 0.969976 db shows that Quicktime is scaling down in incredibly sensible fashion. It does nothing at all for tracks that wouldn't clip. I don't understand why it is called an "issue" and why anyone would want to disable it (and get guaranteed clipping at these levels). It's not a bug, it's a feature!

This post has been edited by rpp3po: Feb 5 2010, 00:16

[richard123]

Are these bitrates values correct for qtaacenc?:

[i]Target Quality - True VBR AAC (Powered by QuickTime & CoreAudio):
Q50 - Q58 = ~115 kbps

In the listening test thread, two testers got ~128 kbps for Q58

http://www.hydrogenaudio.org/forums/index....st&p=685645

[rpp3po]

In the listening test thread, two testers got ~128 kbps for Q58

Nope, it was Q59.

[richard123]

Nope, it was Q59.

Oops. I used to be able to read.

In that case, your result of 129kbps is close to wkmax's

Q59 - Q68 = ~135 kbps

[gaekwad2]

I don't understand why it is called an "issue" and why anyone would want to disable it (and get guaranteed clipping at these levels).

Because, I assume, they use Replaygain which, unlike QuickTime's limiter, will prevent clipping without affecting dynamics (though, whether it makes an audible difference...).

Besides, it's not always strong enough to prevent clipping anyway:

(--tvbr 100 --highest, encoded from FLAC wich has an album gain of -11.36dB)

[rpp3po]

Because, I assume, they use Replaygain which, unlike QuickTime's limiter, will prevent clipping without affecting dynamics (though, whether it makes an audible difference...).

ReplayGain cannot prevent clipping that has already happened. Or is AAC unclippable if you output to float?

This post has been edited by rpp3po: Feb 5 2010, 20:33