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?

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.

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:



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.

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.

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.

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

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

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

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.

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

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.

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.

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)

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.

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?

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.

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

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.

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

Actually there have been complaints about iTunes on the Mac:



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

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

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?

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

But from the same test http://www.hydrogenaudio.org/forums/index....mp;#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.

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.


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

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

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.