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 (http://tmkk.hp.infoseek.co.jp/xld/index_e.html)) 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?
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...
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 (http://www.hydrogenaudio.org/forums/index.php?showtopic=60347).
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?
I want to bring up the possibility, that this thread's conclusions might be completely wrong.
The reason hides behind this simple 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.
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.
There is an Encoder update in the new QuickTime Version.
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.
Just tried the codec and i'm wondering, why the coding at Q80 to 32hz downsamples. Can anyone confirm this?
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?
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.
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.
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).
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.
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.
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.)
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.
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.
It's not user friendly to get AAC .mp4 files in QuickTime, details can be found:
http://developer.apple.com/technotes/tn2008/tn2237.html (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.
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.
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.
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.
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.
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.
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.
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 (http://gallery.me.com/davesprou#100012/Quicktime%20Comp.&bgcolor=black)
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 (http://pastebin.com/fc6a02e)
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.
I tried some test samples and find that quality is pretty on the same level for 96 kbps true VBR.
Well then.
(Clearly I've been away from HA for far too long.)
I did a few listening tests with the new version of QT (CBR and Constrained VBR only), and I definitely heard a (good) difference. I actually used the Apple feedback submission and wrote a fairly lengthy message about pre-echo, and other issues I had with their encoder. I really, really doubt that it actually caused the change, because I would imagine that it was on their roadmap, but it was about a month or two before this latest version came out... so... who knows?
Anyway, I have yet to check the True VBR settings for quality and all that. Good to see that the thread's been of use to people... even if my methods didn't necessarily produce accurate responses.
Kudos to Apple for workin' on it.
one more note: besides being a clumsy process (get quicktime pro, encode to quicktime movie, then encode to mp4, without a command line interface), the only way to get a quicktime vbr (true vbr) file on windows also has the effect of stripping all the tags (even when using apple lossless as the source). ---so it's hard to imagine using it over the nero encoder, without its showing significant superiority. (The quicktime player export menu also sometimes gives errors back on network file operations.)
(Is a new release of the nero encoder expected soon? I think there were a couple of suggestions made to improve the current available release.)
As far as I know Nero prepares its new encoder for public test at around of 80-100 kbps.
We are working on new version, but without any specific bitrate target. All bitrates are important, but one should have in mind that it is hard to improve bitrates > 128 kbps.
one more note: besides being a clumsy process (get quicktime pro, encode to quicktime movie, then encode to mp4, without a command line interface), the only way to get a quicktime vbr (true vbr) file on windows also has the effect of stripping all the tags (even when using apple lossless as the source).
Before I had switched to a Mac and got to know the excellent XLD, there was a way to employ dBpowerAMP (or was it Foobar?) and an AutoIt script to control Quicktime. That way you could batch encode Apple AAC files including tags.
But it's still probably less fuss to just get a cheap Mac. After 20 years of PC use and computer science studies I was happy to never look back. OS X just is the superior interface between human & machine. But that's really too offtopic......
yes it is, why exactly do we have to use the qt encoder again? (linux mint seems to have a nice interface as well..., especially the fluxbox edition, main is cool as well, especially since it comes with preinstalled gnome DO)
yes it is, why exactly do we have to use the qt encoder again?
You don't have to, there are other good codecs. But in my opinion QT 7.6 (true VBR, Q127) marks a new high regarding the sweet spot between transparency vs. space efficiency. I have always done extensive testing on very good equipment. Nero 1.0.7.0 was already great long time ago and better than QT had ever been until then. But today it's very impressive too see how QT 7.6 outputs 105 kbit/s and 240 kbit/s tracks at the same (maximum) quality setting and how they are both completely transparent. You can just let it go. It's also impressive, as said before, how radically QT lets the bitrate jump from frame to frame, which is fine as AAC frames are not interdependent by design. Since encoder complexity can actually be decreased for such a behavior, I ask myself why AAC encoders haven't always been like that. Nero, for example, shows much less fluctuation as if it would carry a bit reservoir between frames, which shouldn't be needed for true VBR, but might have historical reasons within the code base.
today it's very impressive too see how QT 7.6 outputs 105 kbit/s and 240 kbit/s tracks at the same (maximum) quality setting and how they are both completely transparent
is that some sort of a trick question/fact?
(ok, i need to find what to clicky for quote yet, so italics should do for now.)
It's also impressive, as said before, how radically QT lets the bitrate jump from frame to frame, which is fine as AAC frames are not interdependent by design
jumpy must be good.
But today it's very impressive too see how QT 7.6 outputs 105 kbit/s and 240 kbit/s tracks at the same (maximum) quality setting and how they are both completely transparent.
Your point being? I have seen the bitrate drastically jump when using Nero AAC and Lame mp3. I have this one album that makes both Lame and Nero jump all over the place. One song will come out with an overall average bitrate of 130kbps (Nero -q0.5) and 150kbps (Lame -V 2) while another track will jump up to 220kbps (Nero -q0.5) and 260kbps (Lame -V 2). Yes, it is nice that a VBR encoder actually has VBR behavior but your comment can be applied to basically any VBR encoder with true VBR encoding enabled whether it be Nero AAC, Lame mp3, WMA, iTunes/QuickTime AAC, and so on. That is like saying "I bought a car and I am surprised that I can drive from point A to point B." It would be really impressive for Apple to implement true VBR encoding in iTunes.
Just read the beginning of the thread. All VBR implementations fluctuate, that's not the point. But AAC allows true independent frame-based rate control. MP3 does not because there can be dependencies between frames. So by format definition and restriction your LAME tracks cannot fluctuate as much as AAC tracks. Until Quicktime true VBR, there wasn't a codec, yet, to fully exploit that possibility. For example, looking at bitrate curves of Nero tracks there still seems to be some kind of stream based rate control (as in MP3 VBR) and not a solely frame based one.
QT true VBR doesn't have to be better just because of that. Quality still depends mainly on the quality of the implementation, which is very high in the case of Nero. But given you have comparable development ressources in theory you should be able to squeeze out more quality per byte out of a completely frame based approach (in the case of AAC) than a stream based one. The encoder's complexity can be decreased considerably. Less critical decisions have to be made at runtime. And if you look at the results in terms of quality and filesize, QT 7.6 true VBR is working out excellently and worth consideration.
Of course all we are talking about here is marginal. But anybody not interested in marginal differences in audio encoding could have stopped reading these forums years ago.
I'm not going to get into a mac vs pc comparison, but on a pc, the quicktime player is not good--the interface is not designed with windows in mind and seems like a mere port of something designed for another OS. until someone (presumably with a mac) does a good test and shows that qt true vbr aac may be significantly better than nero aac (--I realize that's a chore), I don't think it's worth the bother. (maybe quicktime X will correct these problems, but quicktime has been around forever.)
if you look at the results in terms of quality
what are those results?
if you look at the results in terms of quality
what are those results?
My personal results are I couldn't ABX any of the tested tracks in my collection at Q127. Platform was a Benchmark DAC 1 and Westone UM2 headphones. They don't actually sound better than my open ones, but usually uncover compression artifacts quite well. The last comprehensive test I did until I found transparency was Nero 1.0.0.7 at q .5. Because ABX testing is a very time consuming task and even the highest quality setting in Quicktime produced on average 30 kbit/s smaller files than Nero at q .5, I did not test how low I could have gone in QT. Also in theory the highest quality setting should lead to the least complexity in the encoder, which increases the probability for consistent results over a broad range of material.
Maybe somebody could enrich the discussion and find a sample where QT 7.6 fails.
I agree BTW that the PC port of both Quicktime Player and iTunes is not very well done. On the Mac iTunes is quite fast and scrolling and searching 10000's of tracks is instantaneous. There's no reason why that shouldn't have been possible to realize on a PC.
Thank you, that is very suggestive, if you are getting transparency with quicktime true vbr at a setting 30 kb/s lower than with nero (abx with both encoders using the same music selections--with classical selections?). I think if the difference is that strong, someone with a mac on this site might be tempted to do an abx test, qt 7.6 true vbr & nero 1.3.3.0 vbr LC at an equivalent bitrate, perhaps starting with the past problem selections for both encoders. If it really is that much better (that's more than "marginal," at least for here), then I could use the sdk to get a win32 command line interface going.
(nero) We are working on new version, but without any specific bitrate target. All bitrates are important, but one should have in mind that it is hard to improve bitrates > 128 kbps.
Thank you for the hard work, and I look forward to the new release. (I still use over 128 kbps now.)
edit: These results look good for qt:
http://www.hydrogenaudio.org/forums/index....showtopic=66949 (http://www.hydrogenaudio.org/forums/index.php?showtopic=66949)
I would be interested in those results as well. As I have found transparency vs. wav at acceptable average rates (~184kbit/s) I have no urgency to conduct those tests myself. If a current Nero (1.0.0.7 was quite a while ago) would show benefits against QT, I could imagine using it via Wine, which works well. I don't know if so much has actually improved in the higher bitrate range, though, as most updates I remember focused on the lower range.
Out of technical curiosity I would also appreciate a comment by a Nero dev, wether my conclusions concerning Nero's rate control are utterly false, which I still consider possible. Does your encoder allocate bits completely independent on a frame by frame basis in VBR mode? ABR and CBR mode cannot work this way and have to look at sequences of frames before deciding which gets what. So does your VBR implementation use the same encoding chain as the former two, just with less restrictions or do you feed a separate encoding chain frame by frame for true VBR? Nero's output looks as if frames were not as independent from each other as they could, but there might be other reasons or wrong conclusions on my side.
Maybe somebody could enrich the discussion and find a sample where QT 7.6 fails.
The Fatboy sample always caused obvious artifacts (a type of hissing noise) with QT AAC even at high bitrates, but to my ears this seems to have been fixed, or at least radically improved, with the q127 setting in 7.6. I only had time to do a brief listen, no blind testing, but it could be a good potential killer sample to abx.
Just read the beginning of the thread. All VBR implementations fluctuate, that's not the point. But AAC allows true independent frame-based rate control.
I understand. It is just your wording of "QT 7.6 outputs 105 kbit/s and 240 kbit/s tracks at the same (maximum) quality" doesn't look at each individual frame, it looks at the overall average bitrates. So this point is mute as both Nero AAC and Lame mp3 can produce tracks with vastly different bitrates just like QuickTime. That was what I way trying to get across.
Additionally, these "benefits" that QuickTime's AAC encoder are only benefits if they result in an increase in audible quality. I am not trying to start an argument here but I have seen this type of thinking before when AAC was first introduced. Many people and companies claimed about the technical superiority of the AAC format yet the Lame mp3 encoder was still able to outperform these AAC encoders. I don't know if you remember any of this as it was back in 2003 (and even before then) when Apple made AAC "mainstream." Apple touted all of the benefits of their AAC encoder yet Lame was able to produce the same audible results (there were some samples that were even better with Lame).
That is why I agree that blind ABX tests are in order. I would conduct them myself but I am running Windows and I really don't want to go through the trouble of encoding with QuickTime. I have already conducted ABX tests with Lame 3.97, 3.98.2, iTunes AAC (using the latest version of Quicktime and the constrained VBR setting) and the latest Nero but I would spend all afternoon trying to encode files with QuickTime pro. With my luck, I would determine that Nero AAC, iTunes AAC, or Lame mp3 were fine for my needs. Due to the complex encoding process, it isn't like I would rely on QuickTime for my AAC encoding needs anyway.
I agree BTW that the PC port of both Quicktime Player and iTunes is not very well done. On the Mac iTunes is quite fast and scrolling and searching 10000's of tracks is instantaneous. There's no reason why that shouldn't have been possible to realize on a PC.
Actually there have been complaints about iTunes on the Mac:
Scot Hacker of BeOS bible fame got into this in the 2002 holiday season. His copy of iTunes - using the equivalent of NSTableView - was grinding to a halt with 5,000 songs and his father's copy with 15,000 songs became impossible to use.
But then again 2002 is awhile back. I've had no trouble, but I've only got around 2,000 tracks. Here's the link (http://rixstep.com/2/2/20080314,00.shtml) if you're interested.
There are so many layers in OS X it's not true:
http://www.osxbook.com/book/bonus/misc/osx...xinternals.html (http://www.osxbook.com/book/bonus/misc/osxinternals/osxinternals.html)
AFAIK, iTunes is 32-bit and mostly written in the older Carbon API. (Do a Command-I on a track in iTunes and look at the path displayed under "Where" on the "Summary" tab. Colons as path separators!). Since that API will not be going to 64-bit one has to wonder whether iTunes will get pretty extensively re-worked at some point.
http://sprinkleofcocoa.blogspot.com/2007/1...ming-vista.html (http://sprinkleofcocoa.blogspot.com/2007/11/there-must-be-cocoa-itunes-coming-vista.html)
Many people and companies claimed about the technical superiority of the AAC format yet the Lame mp3 encoder was still able to outperform these AAC encoders.
Unless I misunderstood his results, igorC's tests at least suggests that qt true vbr might be substantially better than lame mp3: qt scored 4.7 for him @ 100 kbps versus lame scoring 4.5 @ 150 kbps.
Maybe someone with a mac could encode some short samples of music in qt true vbr at q 127, and also provide the wav originals, that is a reasonable sample of types, and also thrown in killers like eig, and it could be downloaded and tested by windows users?
Out of technical curiosity I would also appreciate a comment by a Nero dev, wether my conclusions concerning Nero's rate control are utterly false, which I still consider possible. Does your encoder allocate bits completely independent on a frame by frame basis in VBR mode? ABR and CBR mode cannot work this way and have to look at sequences of frames before deciding which gets what. So does your VBR implementation use the same encoding chain as the former two, just with less restrictions or do you feed a separate encoding chain frame by frame for true VBR? Nero's output looks as if frames were not as independent from each other as they could, but there might be other reasons or wrong conclusions on my side.
ABR and CBR do not look at a sequence of frames before deciding anything, so also for CBR/ABR the amount of bits for a frame is decided on frame to frame basis, just like VBR. The difference between CBR/ABR and VBR is that the amount of bits available to the former is limited based on the frames that came before combined with the bitrate constraint. The psychoacoustics determine how much bits are needed and these calculations may depend on previous audio data. Regarding could or should be more independent, if you hear problems, please provide samples
I agree BTW that the PC port of both Quicktime Player and iTunes is not very well done. On the Mac iTunes is quite fast and scrolling and searching 10000's of tracks is instantaneous. There's no reason why that shouldn't have been possible to realize on a PC.
Actually there have been complaints about iTunes on the Mac:
Scot Hacker of BeOS bible fame got into this in the 2002 holiday season. His copy of iTunes - using the equivalent of NSTableView - was grinding to a halt with 5,000 songs and his father's copy with 15,000 songs became impossible to use.
But then again 2002 is awhile back. I've had no trouble, but I've only got around 2,000 tracks. Here's the link (http://rixstep.com/2/2/20080314,00.shtml) if you're interested.
There are so many layers in OS X it's not true:
http://www.osxbook.com/book/bonus/misc/osx...xinternals.html (http://www.osxbook.com/book/bonus/misc/osxinternals/osxinternals.html)
AFAIK, iTunes is 32-bit and mostly written in the older Carbon API. (Do a Command-I on a track in iTunes and look at the path displayed under "Where" on the "Summary" tab. Colons as path separators!). Since that API will not be going to 64-bit one has to wonder whether iTunes will get pretty extensively re-worked at some point.
http://sprinkleofcocoa.blogspot.com/2007/1...ming-vista.html (http://sprinkleofcocoa.blogspot.com/2007/11/there-must-be-cocoa-itunes-coming-vista.html)
I have just under 24,000 songs in iTunes on s one+ year old MacBook.
Not at all slow, and certainly not even remotely a trace of "grinding to a halt"
Edit : Yes --- off topic...
edit: These results look good for qt:
http://www.hydrogenaudio.org/forums/index....showtopic=66949 (http://www.hydrogenaudio.org/forums/index.php?showtopic=66949)
But from the same test http://www.hydrogenaudio.org/forums/index....mp;#entry613728 (http://www.hydrogenaudio.org/forums/index.php?showtopic=66949&st=0&p=613728&#entry613728)
I would take those numbers with a lot of care. Holy, what I try to say that I even don't believe myself right now.
Firstly, it's only personal test (1 person).
Second, even the same person can rate differently after some time.
Third, for different hardware setups the results can change very much.
There are a lot of things to get in a count for abx test. I've already suspected that before.
Unless I misunderstood his results, igorC's tests at least suggests that qt true vbr might be substantially better than lame mp3: qt scored 4.7 for him @ 100 kbps versus lame scoring 4.5 @ 150 kbps.
Yes but, no offense to IgorC, I don't think one blind ABX test is enough to show anything other than results for IgorC. You would need to conduct your own blind ABX tests if you wanted to make audio claims on your part (or rely on a public listening test). That is why I would have to conduct my own ABX tests to see if they fall in line with IgorC's results. Individual ABX tests are nice an all but one person's tests should never be relied upon to draw conclusions (unless you are drawing personal conclusions).
of course. I meant only that his test is striking enough to suggest it may be worth testing further. (my ears aren't great, but I'd like to know how guests with better ears will react--and also like to know I'm not accustoming myself in some way to bad music, at least not more than I'm doing with restaurant music etc.) Besides, with all encoders being tied in the last test, it's good to have a little excitement. In a few years, everyone will be using lossless anyway--one won't be able to find an mp3 player smaller than 1 TB.
But from the same test http://www.hydrogenaudio.org/forums/index....mp;#entry613728 (http://www.hydrogenaudio.org/forums/index.php?showtopic=66949&st=0&p=613728&#entry613728)
Thanks for pointing that out--it's an important qualification, but still the relative quality difference at this bitrate level, if it holds up (i'm assuming roughly same listening conditions for the encoders compared), would be of interest (qt would have a better strategy, though the lack of higher quality settings might mean you wouldn't use it).
Maybe somebody could enrich the discussion and find a sample where QT 7.6 fails.
The Fatboy sample always caused obvious artifacts (a type of hissing noise) with QT AAC even at high bitrates, but to my ears this seems to have been fixed, or at least radically improved, with the q127 setting in 7.6. I only had time to do a brief listen, no blind testing, but it could be a good potential killer sample to abx.
I just tested the first 5 secs of Fatboy Slim's Kalifornia double blind and I can't hear any difference. WAV vs. TVBR Q127. The Fatboy sample is currently offline at LAME. If anyone is interested, try those two as a temporary alternative and guess which (http://www.verprime.com/Fatboy1.wav) is which (http://www.verprime.com/Fatboy2.wav).
In a few years, everyone will be using lossless anyway...
We are hearing this for a while now. I'm not sure about that. My music collection measured in lossless bytes has increased faster than storage prices per byte have decreased for several years. The only option to keep the size increase below the price decrease was going HQ lossy. I couldn't store my whole music collection today losslessly even on the biggest iPod and I probably won't be able in 10 years. iPod's will be bigger, but also my collection. So for the foreseeable future high quality lossy encoders will have their raison d'être.
QuickTime 7.6.2 is out. Any improvements?
QuickTime 7.6.2 is out. Any improvements?
Distortion heard in Kraftwerk reported in http://www.hydrogenaudio.org/forums/index....showtopic=70442 (http://www.hydrogenaudio.org/forums/index.php?showtopic=70442) was fixed.
That's great news!
there is also a noticeable increase in encoding speed, at least on my end (average speed when using v. 7.6 was ~25-26x, and and now with 7.6.2 it regularly averages between 28-29x)... would be nice if someone else could verify this, though.
I also tried AAC true vbr lately Q127 quality encoding set to MAX and i must say that it's pretty good but i don't wether are my ears or not i feel like voices are a bit,how could i say,unclear. Instead AAC 320 ABR MAX encoding quality feels good. What do you think? VBR is supposed to be a lot better anyway,for costant quality.
Larson, your ears can't lie. If you want to know whether you really hear a difference try doing an ABX test between the 127 kbps and the original or the 320 kbps encoding.
As for me Quicktime 128 kbps AAC used to annoy me a little, but not any more since a few versions. I generally use 128 kbps VBR and occasionally 160 kbps.
Any low bitrate comparison on quality 80 or so?
there is also a noticeable increase in encoding speed, at least on my end (average speed when using v. 7.6 was ~25-26x, and and now with 7.6.2 it regularly averages between 28-29x)... would be nice if someone else could verify this, though.
to me it averages also between 33-34x,around 30x for sure anyway. I'm still testing,i find it really good and the problems with voiced were only suggestions of my mind. The only thing i'm noticing right now is the it seems to sound a bit "flat" compared to an iTunes Plus AAC 256 VBR in general; i guess i should abx it even better then.
I still don't know how on Windows there is no program such as dbpoweramp to easily convert with Quicktime AAC Encoder,just like XLD!
so Snow Leopard is out with Quicktime X (7.6.3) and true vbr AAC has been improved so Q127 uses up to 320 and more bitrates,i tested it and it's really nice (plus XLD uses two cores to encode,much faster). Did anyone test to see how it compares to Nero AAC? New Nero AAC version is in progress so i guess it should be out anytime soon.
We'll see if Apple will release the new quicktime + itunes 9 on september 9 for Windows users and if all can access true vbr.
so Snow Leopard is out with Quicktime X (7.6.3) and true vbr AAC has been improved so Q127 uses up to 320 and more bitrates,i tested it and it's really nice (plus XLD uses two cores to encode,much faster). Did anyone test to see how it compares to Nero AAC? New Nero AAC version is in progress so i guess it should be out anytime soon.
I just noticed this a few seconds ago. I was encoding some files and noticed my AACs are HUGE! I was, like, "WTF?!"
I'm going to have to go back and check all this stuff over again!
W.O.W.
They have REALLY done wonders in v7.6.3. VBR Constrained @ 128 kbps is bloody close to transparent now. I've got picky ears, but it's so close it's scary. I'm particularly sensitive to cymbal smears, and the sample I use to test encoders was damn near transparent (eventually I did hear smearing... but I can almost guarantee that most people probably wouldn't).
For True VBR, q75 now equals what used to be 100 (roughly). And going up in steps of 5 doesn't cause for the same output in terms of bitrate/size (at least from what I can tell).
Well done Apple!
VBR Constrained @ 128 kbps is bloody close to transparent now
if you don't mind my asking, is there a particular reason you opted for VBR Constrained @ 128kbps vs. True VBR @ -q65? I can't imagine that there could be any quality gains from boxing in the encoder versus letting it encode as freely as possible, but I was moreso just curious about your choice (or if you were just sharing your results from testing different parameters).
I don't want to speak for ozmosis but that probably has to do with the settings that iTunes uses. In other words, the VBR constrained setting is used by iTunes and you have to access QuickTime Pro (or XLD) in order to use true VBR encoding. That may all change tomorrow but, right now, only CBR and VBR constrained settings are used by iTunes.
Due to the apparent quality improvements of QuickTime 7.6.3, I wonder if Apple will finally stop using 256kbps VBR as the default ripping/encoding setting in iTunes. I had to help someone today as their 8GB iPod nano was completely filled despite having about 1700 songs on it. They simply downloaded iTunes, installed it, and started ripping their CDs without changing the settings. All of their files were encoded at 256kbps VBR (the iTunes Plus setting). I had the person conduct a few blind ABX tests and it turns out that the iTunes Plus setting is about twice as much as they needed.
I thought it was rather "silly" that Apple made that the default ripping/encoding setting in iTunes. This isn't the first time that I have encountered someone like that.
I don't think it's silly. An 8GB Nano was never meant to hold your entire library.
And since when do people buy and use only what they need? Do you need 268HP to get to work everyday?
I don't want to speak for ozmosis but that probably has to do with the settings that iTunes uses. In other words, the VBR constrained setting is used by iTunes and you have to access QuickTime Pro (or XLD) in order to use true VBR encoding. That may all change tomorrow but, right now, only CBR and VBR constrained settings are used by iTunes.
point taken, though based on what ozmosis has shared, he/she seems to already have access to XLD or some other means of encoding via QuickTime's True VBR settings, and based on that I was just curious about his/her choice in Constrained VBR over True VBR. I actually used Constrained VBR through iTunes (the simpler route that you mentioned) prior to Apple's releasing QT 7.3, at which point I discovered the advantages of True VBR... and while my current workflow is just slightly more tedious/time-consuming compared to just popping in a cd and importing it through iTunes as I had been doing, I'm much more satisfied with the results (hence my question).
Due to the apparent quality improvements of QuickTime 7.6.3, I wonder if Apple will finally stop using 256kbps VBR as the default ripping/encoding setting in iTunes. I had to help someone today as their 8GB iPod nano was completely filled despite having about 1700 songs on it. They simply downloaded iTunes, installed it, and started ripping their CDs without changing the settings. All of their files were encoded at 256kbps VBR (the iTunes Plus setting). I had the person conduct a few blind ABX tests and it turns out that the iTunes Plus setting is about twice as much as they needed.
I thought it was rather "silly" that Apple made that the default ripping/encoding setting in iTunes. This isn't the first time that I have encountered someone like that.
agreed, it seems that in regards to at least their music downloads/iTunes, Apple have become more concerned about selling iPods than with offering music with a reasonable quality/filesize (either sold in the iTunes Store or imported with iTunes), at least for the large majority of iPod users for whom 256kbps audio of
any format is a ridiculous amount of overkill... honestly, though, I've spoken with quite a few people who, even with little to no ABX-ing experience, would tell me that music that they "imported with iTunes" sounded "funny" (which I assume is a non-technical reference to the smearing and other artifacts commonly found at lower bitrates, i.e. iTunes' original default setting of 128kbps CBR). my guess is that Apple were aware of this and as a result made the jump toward selling their music (and setting default import settings in iTunes) at a much higher quality/filesize- though why they made such a huge jump is beyond me... unfortunately, though, it's next to impossible to explain any of this to someone who just uses iTunes because it's the "only way to get music on my iPod."
it seems that in regards to at least their music downloads/iTunes, Apple have become more concerned about selling iPods than with offering music with a reasonable quality/filesize
It's all about perception. Amazon and Walmart are both selling 256kbps mp3s. They can't give out the perception that their store is second rate.
I don't think it's silly. An 8GB Nano was never meant to hold your entire library.
And since when do people buy and use only what they need? Do you need 268HP to get to work everyday?
No but that is less than half of what it "should" hold (according to the specs on Apple's website and the iPod box). Well, I use what I need. I have a coupe Honda Civic that has about 160 HP. I can go nearly 500 miles on a single tank of gas and I drive back and forth two hours a day to get to work. So yeah, that is exactly what I need. I don't see anything wrong with the person complaining about their iPod getting filled up while having a lot less on it than the advertised number of songs. They actually purchased an iPod to hold their entire library. Nothing wrong with purchasing an 8GB player to do just that especially whenever their library was only 1GB in size at the time they purchased their player and they purchase about 2GB of music per year.
They released QuickTime 7.6.4 with HE-AAC Support. I guess iTunes and the iPhone can now handle this kind of codec.
itunes 9 also released. Apparently there's no true vbr AAC but HE AAC,can anyone confirm?
itunes 9 also released. Apparently there's no true vbr AAC but HE AAC,can anyone confirm?
No true VBR still, but HE-AAC encoding is support though.
itunes 9 also released. Apparently there's no true vbr AAC but HE AAC,can anyone confirm?
I can confirm HE-AAC support: http://www.hydrogenaudio.org/forums/index....showtopic=74675 (http://www.hydrogenaudio.org/forums/index.php?showtopic=74675)
Anyone interested in an AAC listening test?
Anyone interested in an AAC listening test?
Yes
Anyone interested in an AAC listening test?
A updated AAC listening test would be interesting.
Was HE-AAC support transferred down to iPods or just in iTunes/QuickTime? A firmware update hasn't been released for my 120GB iPod classic (which is exactly the same as the "new" 160GB iPod classic aside from the hard drive) and I haven't seen it mentioned regarding either iPod shuffle or iPod nano.
Edit: A quick look through the various iPod tech specs pages shows that the iPod shuffle and 5G iPod nano support HE-AAC files. The iPod touch and iPod classic don't support it. Kind of make sense now that a 32GB iPod touch is $299 but Apple is still selling an 8GB model, I am sure HE-AAC support would have been nice for that capacity model. HE-AAC would have been nice for older iPod touch models as well. Apple's tech specs also don't mention HE-AAC compatibility for the iPhone 3Gs. So it looks like the 5G iPod nano and 3G iPod shuffle are the only ones that can playback HE-AAC files.*
*Whenever I say playback, I mean properly playback and not just decode the LC portion of HE-AAC files.
VBR Constrained @ 128 kbps is bloody close to transparent now
if you don't mind my asking, is there a particular reason you opted for VBR Constrained @ 128kbps vs. True VBR @ -q65? I can't imagine that there could be any quality gains from boxing in the encoder versus letting it encode as freely as possible, but I was moreso just curious about your choice (or if you were just sharing your results from testing different parameters).
I was just curious. Since iTunes is the furthest your regular user would go for importing music, 128 kbps VBR Constrained is a good snapshot of what people in general would expect "straight outta the box". I would also imagine that Apple would be working that particular setting to make it as transparent as possible.
For my own library, I encode at
q100 q65 True VBR. (And yes, I use XLD.)
Also interested in a listening test... though I will probably conduct a more thorough one in the future to see if I can afford to lower the Q for my encodes... though that will mean I may have to do another MASSIVE encode. (Remember that, kornchild?) Oh, the horror.
(Edit: Fixed True VBR settings)
Anyone interested in an AAC listening test?
A updated AAC listening test would be interesting.
Indeed! After the release of the new Nero AAC...
Hello. I have 2 questions to make regarding this topic.
Does the nero encoder have true VBR or it's only QT that has this possibility? And if it doesn't is it expected to have true VBR in the new version that's coming soon?
And the 2nd question is: I have the QT pro installed on Windows. I followed the process you described and in the end I got an MPEG-4 Movie file. While encoding with Itunes gives me an MPEG-4 Audio file. Does XLD for example produce a video or an audio file? I think that probably this is not important at all but I am curious to know whether it should be like this or I did something wrong..
- I am under the impression that Nero's encoder is true VBR. However, from what I remember, each frame is not independent of the other. I could be wrong on this as past discussions are in my fuzzy memory bank right now. My own personal observation is that the Nero AAC encoder is able to fluctuate its bitrate more than the VBR constrained setting in QuickTime/iTunes.
- XLD will produce audio files. Technically speaking, on Windows, QuickTime Pro is producing mpeg-4 files containing AAC audio. They aren't necessarily video files as they don't contain an video portion. You follow the same procedure as when making video files. All you have to do is rename them from *.mp4 to *.m4a and you will be set.
I have been convinced in the thread that we both don't remember exactly, that Nero's VBR implementation is as "true" as Quicktime's.
I am under the impression that Nero's encoder is true VBR. However, from what I remember, each frame is not independent of the other. I could be wrong on this as past discussions are in my fuzzy memory bank right now. My own personal observation is that the Nero AAC encoder is able to fluctuate its bitrate more than the VBR constrained setting in QuickTime/iTunes.
about your first point, I was always under the impression that True VBR was a term that could only be applied to an encoder that was both quality-based and completely frame-independent (meaning Nero's VBR setting can't be considered "True" VBR)... though I'm always willing to learn something new if one of the developers or someone who knows more about this could clarify this or provide any input.
and about the second point, I've observed that Nero and Quicktime seem to perform very similarly in points of lesser complexity (i.e. during quieter points in a song), but in most songs that build to a peak/become very complex, it seems like Nero pushes itself up to a certain bitrate and remains there (or at least within +/- 5kbps) until the dynamic of the song backs off, while for these same songs, QuickTime still continues to show a substantial amount of variation in bitrate... similar to you, though, these are just my own personal observations, and I'm sure that a difference in the kinds of music in our libraries could have something to do with it.
New Nero is out,did anyone make any test to see how it compares to the latest true vbr AAC by Apple?
So I just discovered this thread after I found some surprising results.
I'm transcoding my collection to 64kbps he-aac to play back on my mobile, which usually plays back music in noisy environments so transparency isn't paramount.
So i used my mac, encoded using coreaudio a song using these options "64kbps/maximum quality/vbr" which is True VBR, then i used the latest Nero and set target quality at .26 (67kbps)
Here's the surprising results.
apple aac 64kbps setting, max quality, true vbr = 66kbps 2.98mb (foobar2000 file properties)
nero quality .26 = 75kbps @ 2.61mb, so to get nero to around apple's filesize, i increased the quality to .30 and achieved a 88kbps file at 2.92mb.
Really? Why are apple's songs so much bigger for a less average bitrate reported by foobar2000?
I changed the VBR refresh rate in fb2k to 6 times per second and apple's VBR is EVERYWHERE. here's my unscientific view while looking for the lowest/highest bitrates reported in fb2k for the first 60 seconds of the song. i'm comparing nero .30 vs apple because the file sizes are close.
nero .30 = 71kbps low, 98kbps high
apple = 51kbps low, 107kbps high
We're definitely dealing with two totally different algorithms here
edit, updated the apple highest bitrate when i watched the songs again.
Does iTunes 10 bring an improved AAC?
No,it's still the same old quicktime behind. A new quicktime update should be expected with Mac OS X 10.6.5 but we don't know if it's going to update also AAC encoding.