IPB

Welcome Guest ( Log In | Register )

18 Pages V  « < 2 3 4 5 6 > »   
Reply to this topicStart new topic
qtaacenc: a command-line QuickTime AAC encoder for Windows
gaekwad2
post Feb 5 2010, 20:35
Post #76





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



QUOTE (rpp3po @ Feb 5 2010, 20:27) *
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 in this case. It can only work with what it's fed. If that is clipped, the data is gone.

We're talking about decoder clipping, right? Replaygain will prevent it (unless it's applied after converting the decoder's output to integer of course).
Go to the top of the page
+Quote Post
rpp3po
post Feb 5 2010, 20:47
Post #77





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



I didn't think about that. If the energy added by an encoders own filtering doesn't cause overflow, clipping should indeed not happen when decoding to float and then Quicktime's scaling would be unneeded. Does it also scale down if you convert the input to float before feeding it to Quicktime?
Go to the top of the page
+Quote Post
Alex B
post Feb 5 2010, 20:59
Post #78





Group: Members
Posts: 1303
Joined: 14-September 05
From: Helsinki, Finland
Member No.: 24472



QUOTE (rpp3po @ Feb 5 2010, 21:27) *
Or is AAC unclippable if you output to float?

Yes.

In addition, usually the clipped peaks have an inaudibly short duration. I have not yet seen a successful ABX report or been able to personally ABX such clipping. For a valid test you would need to decode one sample to float and let another sample to clip and after that reduce the volume level of both files an equal amount so that the "float" file will not clip when it is converted to an integer bit depth.

Edit

I was incorrectly speaking about lossless vs lossy instead of two differently decoded versions of a lossy file. Fixed that.

This post has been edited by Alex B: Feb 5 2010, 21:10


--------------------
http://listening-tests.freetzi.com
Go to the top of the page
+Quote Post
lvqcl
post Feb 5 2010, 21:05
Post #79





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



It is possible to multiply input by 0.95 to prevent QT limiter from altering the signal.

Another method: decrease input by 1.505 dB, encode to AAC, then use aacgain to restore volume.
Go to the top of the page
+Quote Post
Alex B
post Feb 5 2010, 21:18
Post #80





Group: Members
Posts: 1303
Joined: 14-September 05
From: Helsinki, Finland
Member No.: 24472



QUOTE (gaekwad2 @ Feb 5 2010, 20:52) *
... Besides, it's not always strong enough to prevent clipping anyway...

I too have noticed that.

For instance here are three samples from my archive.

The encoding settings
FLAC: -8
M4A: QT --tvbr 62 --highest
MP4: Nero -q 0.41
MP3: Lame -V5



This post has been edited by Alex B: Feb 5 2010, 21:24


--------------------
http://listening-tests.freetzi.com
Go to the top of the page
+Quote Post
rpp3po
post Feb 5 2010, 21:38
Post #81





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



QUOTE (lvqcl @ Feb 5 2010, 21:05) *
It is possible to multiply input by 0.95 to prevent QT limiter from altering the signal.


Yes, though I think QT does not apply limiting, at worst attenuation. And I cannot even reproduce that. afconvert doesn't alter the -0.000001db sinus wave I feed it. The aac is just 0.05 db louder than the input WAV at the end.

I also doubt, that even if there was as much as 1db attenuation involved, that anyone of us could ABX it after ReplayGain had been applied.

This post has been edited by rpp3po: Feb 5 2010, 21:41
Go to the top of the page
+Quote Post
Alex B
post Feb 5 2010, 21:47
Post #82





Group: Members
Posts: 1303
Joined: 14-September 05
From: Helsinki, Finland
Member No.: 24472



BTW, all resulting bitrates in my screenshot are dubiously low for the encoded material - especially for the Merzbow sample, which is from the possibly loudest recorded track ever. It is almost like white noise at 0 dBFS as you may guess by checking the FLAC bitrate.

I would have expected the bitrates to be very high, but perhaps the encoders have some kind of built-in sanity checks and they fall back to using a nominal bitrate when the signal doesn't look like a sound that has normal variation.

This post has been edited by Alex B: Feb 5 2010, 21:48


--------------------
http://listening-tests.freetzi.com
Go to the top of the page
+Quote Post
gaekwad2
post Feb 5 2010, 21:52
Post #83





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



QUOTE (rpp3po @ Feb 5 2010, 20:47) *
Does it also scale down if you convert the input to float before feeding it to Quicktime?

Yes.
I converted the FLACs to 32bit float wav files, then fed those directly to qtaacenc.
Foo_bitcompare couldn't find any difference between the resulting files and the ones converted with foobar.
Go to the top of the page
+Quote Post
rpp3po
post Feb 5 2010, 21:55
Post #84





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



Could you please upload 30 sec of a file, that gets attenuated, to the upload section? I'm unable to reproduce it.

This post has been edited by rpp3po: Feb 5 2010, 21:57
Go to the top of the page
+Quote Post
Alex B
post Feb 5 2010, 21:57
Post #85





Group: Members
Posts: 1303
Joined: 14-September 05
From: Helsinki, Finland
Member No.: 24472



QUOTE (rpp3po @ Feb 5 2010, 22:38) *
I also doubt, that even if there was as much as 1db attenuation involved, that anyone of us could ABX it after ReplayGain had been applied.

I am afraid that in the typical Apple style the "feature" is undocumented. For instance, for the public listening test we would need to know exactly in which circumstances the volume level reduction kicks in and also if its amount is constant. If it varies we would need to know how it varies.

A 0.6 dB volume level reduction is too big for a listening test and it must be corrected in a way or another. ABC/HR Java has a built-in normalizer, but because it it only levels the files according to the highest peak level it is useless.




--------------------
http://listening-tests.freetzi.com
Go to the top of the page
+Quote Post
lvqcl
post Feb 5 2010, 22:12
Post #86





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



Test file for QT limiter:all (but one) samples are 0.25, one sample equal to -1.0.
Attached File  test.wv ( 5.61K ) Number of downloads: 179

Encode it to AAC, decode to WAV, multiply by 4 (so that 0.25 became 1.0)
Result:



Go to the top of the page
+Quote Post
Alex B
post Feb 5 2010, 22:28
Post #87





Group: Members
Posts: 1303
Joined: 14-September 05
From: Helsinki, Finland
Member No.: 24472



QUOTE (rpp3po @ Feb 5 2010, 22:55) *
Could you please upload 30 sec of a file, that gets attenuated, to the upload section? I'm unable to reproduce it.

Any loud sample that peaks @ odBFs should do, but I uploaded the three samples I pictured in the above screenshot:
http://www.hydrogenaudio.org/forums/index....showtopic=78476


--------------------
http://listening-tests.freetzi.com
Go to the top of the page
+Quote Post
rpp3po
post Feb 5 2010, 22:52
Post #88





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



Alex, I get 0.999969 track peak for the original Merzbow, but 1.946267 for Quicktime. Isn't that supposed to be lower if it attenuation was happening?

But lvcql's file really shows shows lower peaks against both Nero and the original. And it seems to be applied as limiter with a very long release time. I would want to switch that off, at least for comparisons, but there is just no way to do that in afconvert. And since the effect is applied dynamically, it also cannot be removed by post processing. The only workaround would be lvcql's proposal.

Update: Corrected premature conclusions.

This post has been edited by rpp3po: Feb 6 2010, 01:23
Go to the top of the page
+Quote Post
Larson
post Feb 7 2010, 11:00
Post #89





Group: Members
Posts: 131
Joined: 27-March 09
Member No.: 68422



Nao could you also give us instruction for a CLI dbpoweramp version of this? thank you so much for all of this and keep up the good work!
Go to the top of the page
+Quote Post
nao
post Feb 7 2010, 12:09
Post #90





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



QUOTE (Larson @ Feb 7 2010, 19:00) *
Nao could you also give us instruction for a CLI dbpoweramp version of this?

Are there any difficulties? For example:
Go to the top of the page
+Quote Post
matt_t
post Feb 7 2010, 17:12
Post #91





Group: Members
Posts: 38
Joined: 18-April 08
Member No.: 52878



QUOTE (nao @ Feb 7 2010, 11:09) *
QUOTE (Larson @ Feb 7 2010, 19:00) *
Nao could you also give us instruction for a CLI dbpoweramp version of this?

Are there any difficulties? For example:


Just a couple of related questions:

1) Converting mono tracks - is it better to use the "channels" drop-down -> 1 or the channel count DSP? Or something in the command line itself? Or does it not matter?

BTW Using either the drop down or DSP, foobar properties still shows "channels - 2" with mono files, whereas with mono Nero files it shows "channels - 1". Don't know if this is caused by qtaacenc or the QuickTime encoder itself. [dBp properties info is worse - shows channels - 2 with both types of mono AAC files!]

2) For changing sample rates is it better to use the drop-down in the dB CLI encoder or "--samplerate xxx" in the command line? Or doesn't it matter?

Thanks nao.
Go to the top of the page
+Quote Post
nao
post Feb 7 2010, 19:14
Post #92





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



QUOTE
1) Converting mono tracks - is it better to use the "channels" drop-down -> 1 or the channel count DSP? Or something in the command line itself? Or does it not matter?

Nope.

QUOTE
BTW Using either the drop down or DSP, foobar properties still shows "channels - 2" with mono files, whereas with mono Nero files it shows "channels - 1". Don't know if this is caused by qtaacenc or the QuickTime encoder itself. [dBp properties info is worse - shows channels - 2 with both types of mono AAC files!]

The same thing happens to the files created by iTunes, so it should be caused by QuickTime.

QUOTE
2) For changing sample rates is it better to use the drop-down in the dB CLI encoder or "--samplerate xxx" in the command line? Or doesn't it matter?

If you don't want to use the samplerate converter in QT, use the drop-down. Otherwise use the --samplerate option. I can't say which is better.
Go to the top of the page
+Quote Post
Larson
post Feb 9 2010, 12:37
Post #93





Group: Members
Posts: 131
Joined: 27-March 09
Member No.: 68422



thank you nao!it works amazing! Should "highest quality decoded source" be checked? i have tested a bit anyway and i noticed that some songs converted with XLD Q127 MAX have 1 kbps less than Q127 --highest (which is Max),isn't it weird?
Go to the top of the page
+Quote Post
wkmax
post Feb 9 2010, 13:07
Post #94





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



QUOTE (Larson @ Feb 9 2010, 12:37) *
thank you nao!it works amazing! Should "highest quality decoded source" be checked? i have tested a bit anyway and i noticed that some songs converted with XLD Q127 MAX have 1 kbps less than Q127 --highest (which is Max),isn't it weird?


Because maybe qtaacenc uses QuickTime 7.6.5 on Windows OS, instead XLD uses QuickTime 7.6.3 (QuickTime X) on Mac OS X Snow Leopard and QuickTime 7.6.4 on Mac OS X Leopard.

Regards

This post has been edited by wkmax: Feb 9 2010, 13:10
Go to the top of the page
+Quote Post
Larson
post Feb 9 2010, 13:53
Post #95





Group: Members
Posts: 131
Joined: 27-March 09
Member No.: 68422



sometimes it's 2-3 kbps of difference,anway more or less it's there. Probably you're right wkmax,weird that Apple hasn't updated quicktime also on Snow Leopard and Leopard,i mean if there are any improvements with encoding they should have updated on macintosh as well.

This post has been edited by Larson: Feb 9 2010, 13:53
Go to the top of the page
+Quote Post
rpp3po
post Feb 9 2010, 14:10
Post #96





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



I can confirm that the differences are not due to different container encapsulation. The raw AAC tracks also have different sizes.
Go to the top of the page
+Quote Post
nao
post Feb 9 2010, 14:28
Post #97





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



QUOTE
Should "highest quality decoded source" be checked?

I don't know what the option is.

QUOTE
isn't it weird?

Well, it is not a good way to check equivalence by bitrate. You should compare the decoded PCM samples. As far as I've tested the decoded samples are not identical, but almost the same. The difference is much smaller than the difference of --highest vs --normal.

QUOTE (wkmax @ Feb 9 2010, 21:07) *
Because maybe qtaacenc uses QuickTime 7.6.5 on Windows OS, instead XLD uses QuickTime 7.6.3 (QuickTime X) on Mac OS X Snow Leopard and QuickTime 7.6.4 on Mac OS X Leopard.

I don't think the difference of QT version (7.6.3 vs .4 vs .5) matters. I think the difference mainly comes from some environment dependent stuff (compiler, depending floating-point arithmetic routine, etc.). You know different LAME binaries result in subtle difference, even if they are built from the same source.
Go to the top of the page
+Quote Post
wkmax
post Feb 9 2010, 15:18
Post #98





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



QUOTE (nao @ Feb 9 2010, 14:28) *
I don't think the difference of QT version (7.6.3 vs .4 vs .5) matters. I think the difference mainly comes from some environment dependent stuff (compiler, depending floating-point arithmetic routine, etc.). You know different LAME binaries result in subtle difference, even if they are built from the same source.


Thanks again nao, makes sense wink.gif

This post has been edited by wkmax: Feb 9 2010, 15:23
Go to the top of the page
+Quote Post
Steve Forte Rio
post Feb 15 2010, 17:07
Post #99





Group: Members
Posts: 469
Joined: 4-October 08
From: Ukraine
Member No.: 59301



Hello.

I have one question about VBR encoding in QuickTime. I was searching with Google but have not found detailed explanation of Constrained VBR mode.

Is it better or worse than True VBR? . Maybe it gives higher quality than tvbr only at maximum quality settings (--cvbr 320 VS --tvbr 127) but at lower bitrates I can get better quality with true vbr?

This post has been edited by Steve Forte Rio: Feb 15 2010, 17:09
Go to the top of the page
+Quote Post
rpp3po
post Feb 15 2010, 17:29
Post #100





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



There is no technical reason to expect CVBR to be better than TVBR (especially not at high bitrates*). Conceptually TVBR is superior and CVBR is just TVBR with braces. If the TVBR implementation was somehow flawed, it would rather show at lower bitrates (as in the 2010 listening test). The constraint could limit the encoder from dropping too low (but be limited at the same time to scale up where needed).

You'll find explanations of CVBR from Apple's developer documentation, if you use the forum's search function.

In my opinion the sole purpose of the CVBR mode in iTunes is prevention of consumer confusion. They don't want people calling in why their remastered 1940 album comes out at ~90kbit/s when they had chosen 256 kbit/s average. When there's just not that much information to preserve, the TVBR encoder won't hesitate to do it. The CVBR encoder would instead output a higher bitrate and please consumer prejudice (without audible benefit). Consumers are happy, Apple is happy (less support calls): win/win.

* TVBR 127 doesn't drop that low anymore and results in >330kbit/s rates.

This post has been edited by rpp3po: Feb 15 2010, 18:20
Go to the top of the page
+Quote Post

18 Pages V  « < 2 3 4 5 6 > » 
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: 29th November 2014 - 10:04