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: Core Audio/QuickTime True VBR vs. Nero AAC (Read 95093 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Core Audio/QuickTime True VBR vs. Nero AAC

Since the release of QuickTime v7.3, there has finally been a true VBR mode to their AAC encoder. I was curious to see how it would fair against my current codec of choice, Nero's AAC. First and foremost, these tests are not listening tests. I noticed rather odd differences in bitrates after encoding using QT's new VBR mode and decided to investigate further.

I started by encoding the following quality settings:

90 (allegedly ~128kbit/s) / 95 / 100 / 105 / 110 / 115 / 120 / 127 (allegedly ~192kbit/s)

It turns out that q95 outputs files identical to q90, q105 to q100, and both q115 AND q120 to q110, so apparently the quality increases every 10 q's. I use Nero's q0.4 to encode my files which my ears find transparent. This yields an approximate bitrate of ~135kbit/s. The closest setting for QT's VBR mode was q100 (and q105).

X Lossless Decoder (found here) was used in OS X to encode using Core Audio's True VBR mode (with the encoder quality setting set to "High"). foobar2000 was used to encode using Nero's AAC encoder. All songs were taken from FLAC sources (ripped from the CDs themselves).

On to the tests!

"Vicarious" by Tool (Genre: Progressive Metal):
130kbit/s (Core Audio/QT True VBR)
135kbit/s (Nero AAC)

"Architecture of a Genocidal Nature" by Dimmu Borgir (Genre: Black Metal):
142kbit/s (Core Audio/QT True VBR)
159kbit/s (Nero AAC)

"Man Next Door" by Massive Attack (Genre: Trip-Hop):
102kbit/s (Core Audio/QT True VBR)
97kbit/s (Nero AAC)

"Numb" by Portishead (Genre: Trip-Hop):
88kbit/s (Core Audio/QT True VBR)
97kbit/s (Nero AAC)

"Climbing up the Walls" by Radiohead (Genre: Alternative Rock):
147kbit/s (Core Audio/QT True VBR)
136kbit/s (Nero AAC)

"Three Little Birds" by Bob Marley & the Wailers (Genre: Reggae):
173kbit/s (Core Audio/QT True VBR)
136kbit/s (Nero AAC)

"Sympozium" by Dimmu Borgir (Genre: Black Metal):
138kbit/s (Core Audio/QT True VBR)
160kbit/s (Nero AAC)

Average bitrate for all songs: 130kbit/s (Core Audio/QT True VBR), 133kbit/s (Nero AAC)

I also went in and took a look at what the bitrate range was for certain sections of songs. I used foobar2000 with the "VBR bitrate updates per second" set to every 1 second.

"Vicarious" by Tool
0:00-0:44 - Bass & electric guitar riff with minor percussion (sounds like a xylophone).
Core Audio/QT True VBR: Bitrate fluctuates erratically. A bitrate range of 118-147kbit/s (spikes appear "random").
Nero AAC: Bitrate range of 92-113kbit/s (spikes specifically with percussion crescendo, otherwise stays in the 90s).

"Climbing Up the Walls" by Radiohead
0:00-0:11 - Ambient noise and slight feedback.
Core Audio/QT True VBR: Bitrate fluctuates around 170kbit/s.
Nero AAC: Bitrate fluctuates around 130kbit/s.

"Sympozium" by Dimmu Borgir
0:54-1:06 - Heavily processed vocals, blastbeat drumming, consistent use of hi-hat symbal.
Core Audio/QT True VBR: Bitrate range of 128-134kbit/s.
Nero AAC: Bitrate range of 163-165kbit/s (appears to be q0.40's ceiling).

"Three Little Birds" by Bob Marley & the Wailers
0:01-0:13 - Typical reggae drumming (prominent hi-hat sizzle), organ, warm bass guitar tones.
Core Audio/QT True VBR: Bitrate range of 160-181.
Nero AAC: Bitrate peaks at 148kbit/s when open hi-hat is hit, drops to ~118-120kbit/s for rest of sample.

"Numb" by Portishead
0:11-0:36 - Rhythm-driven electronic sounds/instruments. Processed snare drum.
Core Audio/QT True VBR: Bitrate remains around 85-88kbit/s.
Nero AAC: Bitrate fluctuates around 95kbit/s (peak of 104kbit/s). Peaks typically match hi-hat hits.

Conclusion

Is it just me, or does the new True VBR mode in Core Audio/QT seem like it needs a bit of tuning? I was rather surprised to see that a reggae song would have a higher bitrate than two black metal songs. I was also surprised to see that the ceiling Core Audio/QT was so much higher for a quality setting that yielded nearly the same average bitrate as Nero's q0.40.

Thoughts? Comments? Criticisms? Threats?

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #1 –
I've noticed the same thing myself, but I've also made a few observations about the bitrate fluctuations (via Foobar2000)- with the QT AAC encoder thru 7.2, even in VBR mode the bitrate seemed like it was tied to a line as opposed to allowed to fluctuate along with the necessary quality (and in my opinion it performed very well)... but with the new encoder, about every 10 seconds the bitrate jumps up, and then drops down so that, for instance at 192kbps VBR, the "line" I was talking about goes back and forth between 180-185kbps and 215-225kbps.  as opposed to being actual quality-based VBR where the bitrate only increases/decreases based on the complexity of the source.

I've actually moved away from iTunes/QT AAC until this new encoder is tuned better, only because in some cases the "line" drops far below what I'm accustomed to seeing in other quality-based AAC encoders (and vice versa).  as with any v1.0 encoder, though, I have to cut it some slack...
Archive- FLAC (-v 8)
Portable- QuickTime AAC (True VBR/-q 77)

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #2 –
I've been avoiding the new QT encoder as well.

I don't mean to beat a dead horse... or take the thread off topic... but I kept finding quality problems using the VBR_constrained setting of the new encoder in iTunes (I'm on windows or I'd be using full VBR) so I switched back to MP3. I've been told that the new encoder fixed problems of the old encoder, but it seems like it introduced new ones as well.

Some examples of what I'm hearing are in this thread.

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #3 –
I see this thread is now about four months old. Has the AAC encoding problem been reduced with QuickTime 7.5, which was released in early June?

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #4 –
I want to bring up the possibility, that this thread's conclusions might be completely wrong.

The reason hides behind this simple quote:

Quote
I also went in and took a look at what the bitrate range was for certain sections of songs. I used foobar2000 with the "VBR bitrate updates per second" set to every 1 second.


Foobar displays one spot sample per second. That is usually not a problem as there aren't many really "true" VBR codecs, but most often carry some dependencies between several neighboring frames, which flatten the bitrate curve.

But first a little background:

The AAC format does not know interdependent frames as other audio codecs do. That opens up the possibility for completely true, context-free VBR implementations. You can ignore surrounding frames and give as many or few bits to each frame as appropriate. In the case of the highest quality setting that is pretty easy: you just don't make any compromises.

As each AAC data frame decodes by definition to 1024 time-domain samples, we have about 43 frames per second (fps) for 44,1kHz audio data. For "natural"* music it is highly probable, that at least few of those 43 fps contain such complicated sequences, that a frame must be very large to accommodate for it at the required quality level. Natural music and noise are full of overlap, interference, resonance, spatial reflections and so on. So it's also very probable, that a true, context-free VBR codec could show extreme spikes to fully capture those patterns at rather high quality levels (it is different for lower bitrates). Right the next frame could be ultra small.

When you think, that there isn't happening much right now within a test track and call a bitrate spike "erratic" or "random", you might be wrong. Especially when using a 1 second resolution for bitrate dispay. Within each of those seconds there were 43 possibilities to justify a spike and Foobar only roughly calculates the VBR rate on top of every 43rd frame instead of all 43. So you sometimes catch spikes and sometimes don't. That must look erratic, although the reason could be very short and well justified spikes, which didn't even increase overall bitrate that much.

So I would propose reading the results the opposite way and applaud for such a radical VBR implementation. Almost all of my listening tests showed excellent results for Quicktime's true VBR. Today I always go for the highest quality level for everything (XLD: AAC True VBR, Q 127), which still produces very small files for acoustically simple data. For example, only 105 kbit/s total for an Chopin recording by Dinu Lipatti in 1950. It has very limited bandwith and only one instrument so that's totally justified. On the other hand for distorted music QT doesn't hesitate to land above 250 kbit/s. That's exactly what I expect from a VBR codec.

* With "natural" I mean almost everything which isn't generated in a very mathematically exact way as some digital synthesizers work.

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #5 –
I just found out that you can setup Foobar to 40 or more VBR bitrate display updates per second. Just try it and you'll see what an excellent job Quicktime is doing. Right now I'm listening to Boulez' Répons. Within one second there are fluctuations of over 120 kbit per second. But that's exactly following the music, which can jump from silence to broad disharmonic shattering to quiet clarinets at the same speed.

If a AAC VBR implementation is rather easy going and only slightly oscillating around a baseline it's not as VBR as it could be or your music is continuously complex. AAC was designed that way from the ground up. So there's no need to keep the bitrate rather constant to prevent playback devices from choking.

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #6 –
There is an Encoder update in the new QuickTime Version.

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #7 –
Quote from: DocterD on
There is an Encoder update in the new QuickTime Version.

Yup, it's QuickTime 7.6.

Sound quality improvement at higher bit rates (64+ kb/s/chan) can be expected, especially, those tracks that are easy to encounter spatial image distortion.

For offline applications (such as rip a CD), VBR mode with highest quality setting is the recommended configuration.

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #8 –
Just tried the codec and i'm wondering, why the coding at Q80 to 32hz downsamples. Can anyone confirm this?

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #9 –
I'm very excited about the new version . It promises improvements in the upper bitrate range, which hasn't happened for quite some time.

I can't confirm the 32kHz downsampling (and especially not 32Hz  ), as I always go for Q127. Just try it. It's not an 'insane' setting in any way, but very reasonable. Bitrates will stay very low if the source doesn't need it.

Has anybody found any new killer samples, yet?

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #10 –
I'd like to try it, but don't know how to set windows up for m4a/aac quicktime true vbr mode.
1.  do i need to buy quicktime pro, or is the same true/full vbr mode already there in itunes?
2.  is there a command line way to do it?
(I'm using nero aac now, but wanted to compare.)
--thanks.

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #11 –
I believe that you need QuickTime pro but I could be wrong.  I have the pro version of QuickTime 7.6 and am trying to encode an Apple lossless file to AAC right now.  QuickTime is giving me a headache as I cannot find out how to encode an AAC file.  QuickTime is only giving me options to export the file as a movie (without the video, where I can change AAC settings but only use CBR values and can't use their VBR-AAC encoder) or as uncompressed audio.

I think that iTunes still uses the constrained setting when using VBR.  I don't know about a command line option.  There is another thread (here on hydrogenaudio) discussing the possibilities of using QuickTime with a command line encoder.  I suggest that you look there.

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #12 –
Quote from: kornchild2002 on
QuickTime is giving me a headache as I cannot find out how to encode an AAC file.  QuickTime is only giving me options to export the file as a movie (without the video, where I can change AAC settings but only use CBR values and can't use their VBR-AAC encoder) or as uncompressed audio.

Open your file and export it to MOV file. Here you can set AAC VBR. Then open MOV file and export it to MP4 file (without re-encoding).

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #13 –
Well it looks like I won't be trying this out.  I am sorry but there should just be one step when encoding AAC audio in QuickTime, not two.  Oh well.  I guess I will just have to stick with the constrained encoder in iTunes if I want to conduct some tests.  It is strange that Apple would make it so difficult to encode AAC files in QuickTime especially since the company prides themselves on how easy their software and hardware is to use.

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #14 –
Quote from: kornchild2002 on
Well it looks like I won't be trying this out.  I am sorry but there should just be one step when encoding AAC audio in QuickTime, not two.  Oh well.  I guess I will just have to stick with the constrained encoder in iTunes if I want to conduct some tests.  It is strange that Apple would make it so difficult to encode AAC files in QuickTime especially since the company prides themselves on how easy their software and hardware is to use.


I don't know if you have a Mac or not, but you can encode in True VBR AAC using XLD.

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #15 –
I don't have a Mac, and I'm uncool enough never to have wanted one.  I guess it's a pass on quicktime aac true vbr, unless it's shown here to be superior to nero's.  (so installing quick time pro does not change the encoding options in itunes? since it would be possible to use the itunes com interface to encode, though something like this really shouldn't be such a hassle to do.)

Quote from: knucklehead on
Quote from: kornchild2002 on

Well it looks like I won't be trying this out. I am sorry but there should just be one step when encoding AAC audio in QuickTime, not two. Oh well. I guess I will just have to stick with the constrained encoder in iTunes if I want to conduct some tests. It is strange that Apple would make it so difficult to encode AAC files in QuickTime especially since the company prides themselves on how easy their software and hardware is to use.

I don't know if you have a Mac or not, but you can encode in True VBR AAC using XLD.

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #16 –
Quote from: TechVsLife on
I don't have a Mac, and I'm uncool enough never to have wanted one.  I guess it's a pass on quicktime aac true vbr, unless it's shown here to be superior to nero's.  (so installing quick time pro does not change the encoding options in itunes? since it would be possible to use the itunes com interface to encode, though something like this really shouldn't be such a hassle to do.)


I have Quicktime Pro on a Mac --- and I'm really cool ---, and True VBR does not show up as an option in iTunes.
One of those strange things Apple does.

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #17 –
It's not user friendly to get AAC .mp4 files in QuickTime, details can be found:
http://developer.apple.com/technotes/tn2008/tn2237.html

On Mac OS X, the command line tool (afconvert) or XLD is sure a much better way to do it.  For instance, to encode a stereo wav file using VBR mode can be executed at a Terminal:
$> afconvert  in.wav  out.m4a  -d aac  -q 127  -s 3  -u vbrq 127

iTunes doesn't provide the full access of the four encoding modes offered in Apple AAC encoder, but these four encoding modes can be accessed via QuickTime, afconvert or XLD.

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #18 –
Quote from: knucklehead on
I don't know if you have a Mac or not, but you can encode in True VBR AAC using XLD.


I had an iMac and sold it to someone who really needed a new computer for college.  It was ironic because my main computer (which could easily run Windows Vista and we all know how much of a resource hog it is) broke down 1 month after selling my iMac.  Now I am stuck with a Pentium M 1.6GHz tablet PC that takes over 1 minute to boot Windows XP.

Either way I am no longer using Mac OS X.  It is kind of sad that Apple doesn't allow iTunes to use the true VBR encoding method offered by QuickTime.  I just refuse to go through two different steps to make one VBR AAC file.  I would rather just test the encoder using iTunes and the restrained setting.  I know that the restrained setting does not allow for full VBR encoding but it just isn't worth my time to go through two steps to encode each file.  I did this for one song and it took a couple of minutes.  That would mean that it would take me about 40 minutes to encode songs for a proper ABX test while iTunes can encode 20 songs in about 5 minutes.

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #19 –
Quote from: kornchild2002 on
It is kind of sad that Apple doesn't allow iTunes to use the true VBR encoding method offered by QuickTime.  I just refuse to go through two different steps to make one VBR AAC file.  I would rather just test the encoder using iTunes and the restrained setting.  I know that the restrained setting does not allow for full VBR encoding but it just isn't worth my time to go through two steps to encode each file.  I did this for one song and it took a couple of minutes.  That would mean that it would take me about 40 minutes to encode songs for a proper ABX test while iTunes can encode 20 songs in about 5 minutes.


I made a simple automator script to do this (on OS X). I happily trashed it after discovering XLD.

I have a feeling that the true VBR option will become available in iTunes when OS 10.6  and the overhauled/upgraded QuickTime X are released.

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #20 –
I've made some comparisons. The new encoder (XLD: Q127, Max) produces at least 5% smaller files throughout a broad range of classical music. As thankful as I am for the proclaimed "fidelity" optimizations, I really don't think that Q127 needed even smaller files. Some Q127 tracks have now shrunken to 101 kBit/s (compared to 106kBit/s in the last revision). Those are bandwidth limited remasterings from old recordings.

The encoder might just be more consequent than my prejudices towards bitrates, but at least it looks strange to have 101kBit/s tracks in a highest-quality-setting collection. It would be nice to hear if skuo could confirm that this is really no reason to worry.

Frankly speaking I could neither ABX the 101 kBit/s nor the 106 kBit/s track against the original WAV. Even the strange chorus like artifacts from the old recording were preserved perfectly.

Quote from: Pepzhez on
I have a feeling that the true VBR option will become available in iTunes when OS 10.6  and the overhauled/upgraded QuickTime X are released.


I doubt that. If even enlightened HA regulars have a "bad feeling" about 101 kBit/s encodes (probably against all facts), imagine the support costs for answering questions like those from the whole global iTunes mob.

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #21 –
Quote from: Pepzhez on
I made a simple automator script to do this (on OS X). I happily trashed it after discovering XLD.

I have a feeling that the true VBR option will become available in iTunes when OS 10.6  and the overhauled/upgraded QuickTime X are released.


As much as I would like to see that, I don't think it will happen.  I agree with rpp3po's point in that too many people would get confused.  Remember when iTunes 7.6 (or something like that) was released?  People could enable VBR encoding and iTunes would display the overall average bitrate.  This means that 128kbps VBR iTunes AAC files would often be displayed as being 133kbps or 125kbps.  Many were confused as to why iTunes was showing a different bitrate for their newly encoded content.  Even files that were encoded using "CBR" would show a different bitrate.  192kbps iTunes AAC files were being displayed as 194kbps, 256kbps files as 260kbps, and so on.  People complained on the forums, they e-mailed Apple, they called, Apple, and they just didn't understand that the iTunes was just displaying the overall average bitrate of a song encoded with iTunes AAC.

Apple quickly released iTunes 7.6.2 (or something like that) and iTunes no longer displayed files like that.  It would look at what setting the person used for encoding AAC files and simply display that.  So 128kbps VBR/CBR files would show up as being 128kbps (even though their overall average bitrates did not have that value), 192kbps VBR/CBR files as being 192kbps, and so on.

I would love to see true VBR encoding but Apple would have to set it up so that iTunes doesn't display the overall average bitrate but rather the quality setting.  Displaying even a close bitrate would not work.  For example, take rrp3po's 101kbps VBR AAC files.  iTunes could say that the file had a bitrate of 128kbps (VBR) but even then people wouldn't understand how a file could come out with such a low bitrate when using the highest quality setting.  It would work if iTunes would display the quality setting but some people might look at the file size, the length of the track, and then kind of figure out that the file size is "too small" for such a high quality setting.

I can understand why Apple continues to use the constrained setting in iTunes as it produces files with predictable sizes and predictable bitrates.  That way the common iTunes user community won't get confused about what iTunes is showing them.

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #22 –
Quote from: rpp3po on
I've made some comparisons. The new encoder (XLD: Q127, Max) produces at least 5% smaller files throughout a broad range of classical music. As thankful as I am for the proclaimed "fidelity" optimizations, I really don't think that Q127 needed even smaller files. Some Q127 tracks have now shrunken to 101 kBit/s (compared to 106kBit/s in the last revision). Those are bandwidth limited remasterings from old recordings.

The encoder might just be more consequent than my prejudices towards bitrates, but at least it looks strange to have 101kBit/s tracks in a highest-quality-setting collection. It would be nice to hear if skuo could confirm that this is really no reason to worry.

Frankly speaking I could neither ABX the 101 kBit/s nor the 106 kBit/s track against the original WAV. Even the strange chorus like artifacts from the old recording were preserved perfectly.

Quote from: Pepzhez on
I have a feeling that the true VBR option will become available in iTunes when OS 10.6  and the overhauled/upgraded QuickTime X are released.


I doubt that. If even enlightened HA regulars have a "bad feeling" about 101 kBit/s encodes (probably against all facts), imagine the support costs for answering questions like those from the whole global iTunes mob.


For what it's worth - The only comparison I've done so far showed just one track that came in at a lower bit rate (113 --> 110), and all the rest came in higher.

QuickTime Comparison

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #23 –
I have finished the first batch of encoding with Quicktime 7.6 at Q127. 196 classical tracks, some old pieces with limited dynamics.

Average bitrate (old): 177,69 kBit/s
Average bitrate (new): 171,22 kBit/s

-3,8 % overall difference

Raw data here: Pastebin

Download the text file and copy & paste its contents into either Numbers or Excel.

Edit: Removed constrained VBR album (accidentally included) from the set.

Looking at this and knucklehead's data the new Quicktime encoder update doesn't seem to be a minor tweak but a completely new revision.

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #24 –
I tried some test samples and find that quality is pretty on the same level for 96 kbps true VBR.