Apple just released a new version of QuickTime (6.3) on both Windows and MacOS platforms. According to Apple's web site it contains an improved AAC encoder:

QuickTime 6.3



It's time to test the new codec!

Poor Roberto...
In a few days, a new ahead AAC and a new Apple AAC codec...
I hope he can finish soon the material for his blind test ;-)

I can confirm - codec in QT 6.3 is indeed different from codec in QT 6.1 , at least for 128 kbps.

They claim VBR!



The only settings choices are bit rate (8-320 kbits/sec) and encoding quality (good/better/best) and sample rate (44.1 khz, etc)

Ouch.

I wonder if it's the same as in QT 6.2. If it is, then no problem with the test.

There is no VBR option in QuickTime 6.3 so I don't understand what Apple means by "true variable bit rate (VBR) encoding". Can anyone comment on that ?

Apple fellas are crazy. And clueless.

I can confirm a difference between 6.1 and 6.3 128 kbps encodings (but I can't say which one is better), by a simple substraction on CEP. I can't help you for testing difference between 6.2 & 6.3 (no 6.2 for Win32 systems)

Tested with one sample, I just noticed that BETTER and BEST gave identical results (same stream). Difference in encoding time between GOOD (fastest) and BEST (slowest) mode is pretty small (files are different).

Interesting...

I will probably reencode everything to 6.3 anyway, just to be sure. I'm waiting for some solution to the ABC/HR bug anyway...

I didn't understand you problem. Doesn't it work, by opening, (decoding) and saving with CoolEditPro ? When I did my own test, I decoded all mp4/aac files with the batch tool of CEP 2.0, and I didn't encountered any problem.

I think it's not related to the wav files. Because all files decoded with FAAD play perfectly, and the reference file (decoded with FLAC) plays fine if it's played first (before the samples)

It seems that, after I play one of the sample files, a bug triggers and I am not able to play the reference anymore.

I'll test some more now.

I often had the same problem, with AAC decoded files and Vorbis one decoded with OggDropXpd. Save your decoded files with CEP (I think fb2k diskwriter is fine too, but not I'm not as sure), and I'm quite sure that your problem will disapear.

Since I am a MacOS X user, I did a comparison between QuickTime 6.2 and 6.3 encoded files at 128Kbps and 160Kbps. They have slightly different file sizes and when examined using a hex editor they are clearly different. I encoded the famous castanets.flac file with the following results:

castanets-128-QT62 -> 110,611 bytes castanets-128-QT63 -> 110,575 bytes
castanets-160-QT62 -> 137,160 bytes castanets-160-QT63 -> 137,125 bytes

Therefore, the codec is different. Still, if QT is using CBR how come the file sizes are different? Is it possible that QT is using some kind of ABR algorithm with slightly varying bitrates for each frame? Is there any tool which can check the bitrate of each frame?

For the 1000000th time - AAC has bit reservoir which is ~9000 bits for 128 K, so CBR files could be different by up to nearly 9 KB.

Each frame can be anywhere between 0 and 6144 bits, multiplied by the number of channels - as long as the CBR bit buffer rules are not violated - if they are violated, file is either ABR or VBR.

So, something like this:

bit_reservoir = (no_of_channels * 6144 ) - (average_bits_per_frame * no_of_channels)

average_bits_per_frame = bit_rate / number_of_frames_per_second


Frame size can be anywhere between max(0, (min_bits_that_do_not_underflow_bit_reservoir)) and min(6144,(max_bits_that_do_not_overflow_bit_reservoir))

So, bit rate is variable locally, as long as the conditions imposed by the bit reservoir are not violated. Bit reservoir is filled when number of bits used is smaller than average bits per frame, and bit reservoir is drained when number of bits used is greater than average bits per frame.

hello, guruboolez.

Check it here:
http://www.hydrogenaudio.org/forums/index....25&#entry101374

The issue is surely in ABC/HR, not in the wav files.

Now, I wonder if it happens only here, or what.

I suppose aac encoding is a feature of the pro version only?

yup

You can encode via the QuickTime API as well, even with the unregistered version, so if you want to use QuickTime AAC and not pay, you just have to code

Really? That's great.

But are you sure? From the AAClerator home page, I understood you need a registered QT, even if you're just using their frontend:

http://www.macmethod.com/AACelerator.php


Of course, maybe things are different in the Windows platform...

AACelerator is nothing but a frontend for QuickTime Player using AppleScript, and the $12 they charge for it is way too much. Ovolab AAChoo seems to do it the "proper" way using C. Still, $15 is quite a lot to charge for that little functionality...

I agree that the price they ask is somewhat high for just a front-end. Still, I personally decided to buy it because it is the only easy way to encode in AAC using the highest quality setting of the AAC encoder in QuickTime Pro. Note that AACelerator does not allow the setting of the encoding quality. AAChoo can also automatically update the iTunes library so if you ripped a CD in AIFF format you can then encode it using AAChoo and the next time you load iTunes all AIFF files will be replaced by the AAC files together with all appropriate tags. Since QuickTime Pro does not have batch processing capabilities, this is the only practical way to rip CDs.

On the subject of the quality settings in QuickTime Pro, I would direct people to the review performed in the following link:

http://recordstorereview.com/misc/aacmp3part1.shtml

which reveals the big difference in quality when using the default low quality setting that iTunes uses and the high quality setting that can only be enabled by running QuickTime Pro or using the AAChoo utility.

Are there also frontends for Quicktime for the PC?

As far as I know there is no such utility for Windows. Still, Apple is planning to release a Windows version of iTunes and I am sure that this is going to use the AAC codec in QuickTime for AAC encoding like iTunes for MacOS does. As AAC becomes more popular we may see some utility sooner than that though...

http://www.discreet.com/cleanerxl/

At a price of 732.09 Euros, I wouldn't call Discrete Cleaner XL a front-end utility for encoding in AAC using QuickTime's codec !!

Right...

Buying an iMac like mine used and use the mac frontends would probably be cheaper than buying Cleaner. 400MHz iMacs seem to sell for about 400 euro, and they don't suck all that badly

EDIT: Why does HA choke on the euro sign?

A steal at $180

$180 is the update from cleaner 5.

The full version costs $599