IPB

Welcome Guest ( Log In | Register )

18 Pages V  < 1 2 3 4 5 > »   
Reply to this topicStart new topic
qtaacenc: a command-line QuickTime AAC encoder for Windows
tedgo
post Feb 2 2010, 21:35
Post #51





Group: Members
Posts: 1090
Joined: 16-April 04
From: Bavaria, Germany
Member No.: 13548



@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
Go to the top of the page
+Quote Post
b66pak
post Feb 2 2010, 21:38
Post #52





Group: Members
Posts: 58
Joined: 2-February 10
Member No.: 77800



QUOTE (b66pak @ Feb 2 2010, 22:34) *
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...
_
Go to the top of the page
+Quote Post
wkmax
post Feb 2 2010, 22:16
Post #53





Group: Members
Posts: 32
Joined: 30-December 09
From: Chile
Member No.: 76490



QUOTE (tedgo @ Feb 2 2010, 21:35) *
@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)


Go to the top of the page
+Quote Post
lvqcl
post Feb 2 2010, 22:40
Post #54





Group: Developer
Posts: 3467
Joined: 2-December 07
Member No.: 49183



ALAC never clips.
Go to the top of the page
+Quote Post
wkmax
post Feb 2 2010, 22:49
Post #55





Group: Members
Posts: 32
Joined: 30-December 09
From: Chile
Member No.: 76490



QUOTE (lvqcl @ Feb 2 2010, 22:40) *
ALAC never clips.


Thank you lvqcl, I can sleep peacefully with my ALAC encodings laugh.gif
Go to the top of the page
+Quote Post
greynol
post Feb 2 2010, 22:59
Post #56





Group: Super Moderator
Posts: 10338
Joined: 1-April 04
From: San Francisco
Member No.: 13167



QUOTE (tedgo @ Feb 2 2010, 12:35) *
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"???


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
tedgo
post Feb 2 2010, 23:20
Post #57





Group: Members
Posts: 1090
Joined: 16-April 04
From: Bavaria, Germany
Member No.: 13548



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
Go to the top of the page
+Quote Post
lvqcl
post Feb 2 2010, 23:53
Post #58





Group: Developer
Posts: 3467
Joined: 2-December 07
Member No.: 49183



QUOTE (tedgo @ Feb 2 2010, 23:35) *
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
Go to the top of the page
+Quote Post
greynol
post Feb 3 2010, 00:07
Post #59





Group: Super Moderator
Posts: 10338
Joined: 1-April 04
From: San Francisco
Member No.: 13167



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


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
tedgo
post Feb 3 2010, 00:20
Post #60





Group: Members
Posts: 1090
Joined: 16-April 04
From: Bavaria, Germany
Member No.: 13548



QUOTE (greynol @ Feb 3 2010, 00:07) *
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? mad.gif
Go to the top of the page
+Quote Post
greynol
post Feb 3 2010, 00:28
Post #61





Group: Super Moderator
Posts: 10338
Joined: 1-April 04
From: San Francisco
Member No.: 13167



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.


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
singaiya
post Feb 3 2010, 06:57
Post #62





Group: Members
Posts: 365
Joined: 21-November 02
Member No.: 3830



QUOTE (lvqcl @ Feb 1 2010, 07:35) *
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
Go to the top of the page
+Quote Post
lvqcl
post Feb 3 2010, 16:24
Post #63





Group: Developer
Posts: 3467
Joined: 2-December 07
Member No.: 49183



QUOTE (lvqcl @ Feb 3 2010, 01:53) *
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
Go to the top of the page
+Quote Post
singaiya
post Feb 4 2010, 05:10
Post #64





Group: Members
Posts: 365
Joined: 21-November 02
Member No.: 3830



QUOTE (singaiya @ Feb 2 2010, 21:57) *
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.

Go to the top of the page
+Quote Post
Xire
post Feb 4 2010, 13:56
Post #65





Group: Members
Posts: 34
Joined: 11-May 08
Member No.: 53447



QUOTE (nao @ Jan 22 2010, 13:15) *
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
Go to the top of the page
+Quote Post
nao
post Feb 4 2010, 15:41
Post #66





Group: Members
Posts: 86
Joined: 16-June 06
Member No.: 31911



QUOTE (Xire @ Feb 4 2010, 21:56) *
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.
Go to the top of the page
+Quote Post
rpp3po
post Feb 4 2010, 17:20
Post #67





Group: Developer
Posts: 1126
Joined: 11-February 03
From: Germany
Member No.: 4961



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.
Go to the top of the page
+Quote Post
kornchild2002
post Feb 4 2010, 23:08
Post #68





Group: Members
Posts: 2080
Joined: 8-April 05
From: Cincinnati, OH
Member No.: 21277



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)?
Go to the top of the page
+Quote Post
tedgo
post Feb 4 2010, 23:51
Post #69





Group: Members
Posts: 1090
Joined: 16-April 04
From: Bavaria, Germany
Member No.: 13548



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
Go to the top of the page
+Quote Post
rpp3po
post Feb 4 2010, 23:58
Post #70





Group: Developer
Posts: 1126
Joined: 11-February 03
From: Germany
Member No.: 4961



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! smile.gif

This post has been edited by rpp3po: Feb 5 2010, 00:16
Go to the top of the page
+Quote Post
richard123
post Feb 5 2010, 17:33
Post #71





Group: Members
Posts: 364
Joined: 9-January 03
Member No.: 4498



QUOTE (wkmax @ Jan 24 2010, 06:23) *
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
Go to the top of the page
+Quote Post
rpp3po
post Feb 5 2010, 17:37
Post #72





Group: Developer
Posts: 1126
Joined: 11-February 03
From: Germany
Member No.: 4961



QUOTE (richard123 @ Feb 5 2010, 17:33) *
In the listening test thread, two testers got ~128 kbps for Q58


Nope, it was Q59.
Go to the top of the page
+Quote Post
richard123
post Feb 5 2010, 19:07
Post #73





Group: Members
Posts: 364
Joined: 9-January 03
Member No.: 4498



QUOTE (rpp3po @ Feb 5 2010, 11:37) *
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
Go to the top of the page
+Quote Post
gaekwad2
post Feb 5 2010, 19:52
Post #74





Group: Members
Posts: 127
Joined: 11-April 06
Member No.: 29396



QUOTE (rpp3po @ Feb 4 2010, 23:58) *
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)
Go to the top of the page
+Quote Post
rpp3po
post Feb 5 2010, 20:27
Post #75





Group: Developer
Posts: 1126
Joined: 11-February 03
From: Germany
Member No.: 4961



QUOTE (gaekwad2 @ Feb 5 2010, 19:52) *
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
Go to the top of the page
+Quote Post

18 Pages V  < 1 2 3 4 5 > » 
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 22nd December 2014 - 05:14