QuickTime 6.3 delivers extensive support for 3GPP, including video, audio, text, and native .3gp file format support. Because 3GPP is now a part of the core architecture of QuickTime, you can import, export, and play back .3gp files just as you do .mp4 and .mov files. The technologies in QuickTime 6.3 that provide these capabilities are newly enhanced MPEG-4 and H.263 video codecs, a newly enhanced AAC (Advanced Audio Coding) audio codec, a new AMR (Adaptive Multi-Rate) audio codec, a new 3G Text importer and exporter, and a new user-friendly 3GPP export dialog to aid in the creation of 3GPP-compliant files. This support is available via the QuickTime 3GPP Component.

AAC is the new standard in professional audio. It provides more efficient compression than older formats such as MP3, yet delivers quality rivaling that of uncompressed CD audio. The newly enhanced QuickTime AAC codec builds upon new, state-of-the-art signal processing technology from Dolby Laboratories, and brings true variable bit rate (VBR) encoding to QuickTime. Learn more about

AAC is the new standard in professional audio. It provides more efficient compression than older formats such as MP3, yet delivers quality rivaling that of uncompressed CD audio. The newly enhanced QuickTime AAC codec builds upon new, state-of-the-art signal processing technology from Dolby Laboratories, and brings true variable bit rate (VBR) encoding to QuickTime. Learn more about

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 ?

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

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).

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 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.

--------------------

Get up-to-date binaries of Lame, AAC, Vorbis and much more at RareWares:http://www.rarewares.org

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:

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?

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.

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.

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...

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.

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.

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...