Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Core Audio/QuickTime True VBR vs. Nero AAC (Read 94693 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #25
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.

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #26
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.)

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #27
As far as I know Nero prepares its new encoder for public test at around of 80-100 kbps.

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #28
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.

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #29
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...... 

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #30
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)
PANIC: CPU 1: Cache Error (unrecoverable - dcache data) Eframe = 0x90000000208cf3b8
NOTICE - cpu 0 didn't dump TLB, may be hung

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #31
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.

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #32
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.
PANIC: CPU 1: Cache Error (unrecoverable - dcache data) Eframe = 0x90000000208cf3b8
NOTICE - cpu 0 didn't dump TLB, may be hung

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #33
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.

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #34
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.

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #35
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? 

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #36
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.

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #37
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.

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

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #38
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.

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #39
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.

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #40
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.

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #41
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:

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

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #42
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?

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #43
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

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #44
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:

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


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

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #45
edit: These results look good for qt:
http://www.hydrogenaudio.org/forums/index....showtopic=66949

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.



Core Audio/QuickTime True VBR vs. Nero AAC

Reply #46
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).

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #47
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.

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

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #48
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 is which.

Core Audio/QuickTime True VBR vs. Nero AAC

Reply #49
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.