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: qtaacenc: a command-line QuickTime AAC encoder for Windows (Read 398656 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

qtaacenc: a command-line QuickTime AAC encoder for Windows

Reply #50
@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.

qtaacenc: a command-line QuickTime AAC encoder for Windows

Reply #51
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...
_

qtaacenc: a command-line QuickTime AAC encoder for Windows

Reply #52
@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)



qtaacenc: a command-line QuickTime AAC encoder for Windows

Reply #53
ALAC never clips.


qtaacenc: a command-line QuickTime AAC encoder for Windows

Reply #55
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"???

qtaacenc: a command-line QuickTime AAC encoder for Windows

Reply #56
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".

qtaacenc: a command-line QuickTime AAC encoder for Windows

Reply #57
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!).

qtaacenc: a command-line QuickTime AAC encoder for Windows

Reply #58
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.

qtaacenc: a command-line QuickTime AAC encoder for Windows

Reply #59
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? 

qtaacenc: a command-line QuickTime AAC encoder for Windows

Reply #60
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.

qtaacenc: a command-line QuickTime AAC encoder for Windows

Reply #61
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.

qtaacenc: a command-line QuickTime AAC encoder for Windows

Reply #62
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.

qtaacenc: a command-line QuickTime AAC encoder for Windows

Reply #63
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.


qtaacenc: a command-line QuickTime AAC encoder for Windows

Reply #64
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?

qtaacenc: a command-line QuickTime AAC encoder for Windows

Reply #65
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.

qtaacenc: a command-line QuickTime AAC encoder for Windows

Reply #66
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.

qtaacenc: a command-line QuickTime AAC encoder for Windows

Reply #67
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)?

qtaacenc: a command-line QuickTime AAC encoder for Windows

Reply #68
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: [Select]
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...

qtaacenc: a command-line QuickTime AAC encoder for Windows

Reply #69
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!



qtaacenc: a command-line QuickTime AAC encoder for Windows

Reply #72
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

qtaacenc: a command-line QuickTime AAC encoder for Windows

Reply #73
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)

qtaacenc: a command-line QuickTime AAC encoder for Windows

Reply #74
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?