Well, the best way to answer that question would be for you to conduct your own series of blind ABX tests. What works for one person doesn't necessarily work for another. We don't have your music, equipment, listening environment, tastes, or ears.

In my opinion Quick Time and nero has about the same quality, but QT has a little more flexible VBR mode, so in some cases it can give a little higher quality. But at the same time QT has such problems like limiting of signals with high level (close to 0dbFS) which results in dynamic range compression.

You're saying there's a commandline encoder for QuickTime I can just download? Because I'm using Ubuntu Maverick with WINE and foobar2000 to do the volume normalizations and converting with NeroAACEnc. For some reason LAME wouldn't work with WINE it kept giving me demands for various extra files, doesn't matter since AAC is superior anyway.

In my opinion Quick Time and nero has about the same quality, but QT has a little more flexible VBR mode, so in some cases it can give a little higher quality. But at the same time QT has such problems like limiting of signals with high level (close to 0dbFS) which results in dynamic range compression.

I also find Quicktime to be a lot better than Nero around 128kbps. It's easy to hear when you compare so that's why I haven't done an ABX.

ABX tests are needed, it doesn't matter how "easy" you think it is to hear as you could very well be suffering from the placebo affect. Proper testing is required before anyone makes subjective audio claims, period. That is in the TOS (specifically TOS #8 (http://www.hydrogenaudio.org/forums/index.php?showtopic=3974#entry149481)) that everyone agrees upon when joining the site. So proper test results are needed from both you and list before any audio quality claims can be taken seriously. That and the Nero devs would like to know the performance of their encoder and just what samples their encoder is having issues with. That way they can fine tune their encoder so that Apple's is not "much better" and comparing the two won't be so "easy to hear."

ABX tests are needed, it doesn't matter how "easy" you think it is to hear as you could very well be suffering from the placebo affect. Proper testing is required before anyone makes subjective audio claims, period.

kc2002 just explained that any claim of difference in quality is worth nothing until evidenced by a blind test. Otherwise, expecting to hear differences can cause the listener to hear them where they don't exist.

expecting to hear differences lead you to hear them where they don't exist.

No, i was not expecting to hear any difference. Once i disided to include the qt aac in my gui and make some simple tests using it for video series, and i surprised when i saw the difference at first sight. So i decided to try also with some of my music.. and i said: woow there is a difference. Easy to hear at 128kbps.Im not audio tester, i only noticed a difference and decided to share it here. (i thought people know that difference) so was i wrong?

You're missing the point. When you were comparing the two codecs, did you know which was which? If so, your claim is not objective. Claims of audible differences in sound quality are of no use unless they are backed up by objective evidence gathered in a blind listening test (http://www.hydrogenaudio.org/forums/index.php?showtopic=16295). Subjective claims are proscribed by this site's rules (http://www.hydrogenaudio.org/forums/index.php?showtopic=3974), which users must (at least tacitly) agree to while creating an account.

I can assure you that any difference you think you heard was not there as you don't have my equipment. Only proper audio quality judging can be used on my system with my Denon AKDL1 Dedicated Link Cable ($1,000), pair of AudioQuest K2 terminated speaker cables ($17,000), properly broken in tube amp ($23,000), 48" quad speakers with 45 lb magnetic drivers ($46,700), and Ailenware desktop with external sound card ($7,600) running the Microsoft Zune PC software. I say: Wow, there is a huge difference in listening to audio with what you have and my system is a million bagillion times better than yours. It is so easy to hear that blind testing isn't required.

See why proper testing is needed before any audio quality claims are made? It doesn't matter if the difference is "easy to hear." You need proper testing to backup your claims, period. Don't like it? Well, those are the rules here which you and everyone else agreed upon. There is a reason why that is part of the rules and it is enforced here.

I can assure you that any difference you think you heard was not there as you don't have my equipment. Only proper audio quality judging can be used on my system with my Denon AKDL1 Dedicated Link Cable ($1,000), pair of AudioQuest K2 terminated speaker cables ($17,000), properly broken in tube amp ($23,000), 48" quad speakers with 45 lb magnetic drivers ($46,700), and Ailenware desktop with external sound card ($7,600) running the Microsoft Zune PC software. I say: Wow, there is a huge difference in listening to audio with what you have and my system is a million bagillion times better than yours. It is so easy to hear that blind testing isn't required.

See why proper testing is needed before any audio quality claims are made? It doesn't matter if the difference is "easy to hear." You need proper testing to backup your claims, period. Don't like it? Well, those are the rules here which you and everyone else agreed upon. There is a reason why that is part of the rules and it is enforced here.

After all, encoders will be used by 99% normal users with a normal hardware, right?So, if you can't notice the difference with a high-end equipment, but other does with a simple hardware encoding a not simple movie. Is that important?

I really don't understand what you are saying or the point you are trying to get across. There are rules in place that need to be followed, it doesn't matter what anyone else says. They are a fundamental part of this site and you can either follow them or not participate in the forums. You obviously aren't understanding the need for proper testing in order to backup or refute subjective claims.

The easy way to use it is to feed the comparator with original and decoded lossy files codec_A.wav, codec_B.wav and you are ready for blind test ( Original vs Codec_A, Original vs Codec B). It's also good to do blind test on Codec_A vs Codec_B to be sure that you actually hear the difference.

Quote

So i tried it with a foobar2k abx component with a sample at 128 and got 13/15.is that worth?

While the probability values (in %) is less than 5% your results are valid.

See the table of probability values here http://en.wikipedia.org/wiki/ABX_test (http://en.wikipedia.org/wiki/ABX_test)

I also find Quicktime to be a lot better than Nero around 128kbps. It's easy to hear when you compare so that's why I haven't done an ABX.

ABX tests are needed, it doesn't matter how "easy" you think it is to hear as you could very well be suffering from the placebo affect. Proper testing is required before anyone makes subjective audio claims, period. That is in the TOS (specifically TOS #8 (http://www.hydrogenaudio.org/forums/index.php?showtopic=3974#entry149481)) that everyone agrees upon when joining the site. So proper test results are needed from both you and list before any audio quality claims can be taken seriously. That and the Nero devs would like to know the performance of their encoder and just what samples their encoder is having issues with. That way they can fine tune their encoder so that Apple's is not "much better" and comparing the two won't be so "easy to hear."

I am going to try the classical piece some day but i guess it will be a lot tougher from the little glim that I had at them. Regards. The prodigy track with nero had more high frequencies and the hi hat seemed more open (like not pressing down the pedal as much) and degraded. Quicktime had less high frequencies but more focused hi hat. The hi hat "sustain" seemed to end faster than with Nero. Maybe Nero can archieve about the same quality if a lower low pass is used? Regards.

I tried ogg vorbis which i favour and it was a little more difficult at times to destingish (spelling?) from the lossless. I used the following settings and encoder and the averge bitrate is 130kbps:BS; LancerMod(SSE2) [Nov 25 2009] (based on aoTuV b5d [20090301]) (...)-q 3.5 --advanced-encode-option impulse_noisetune=-7 --advanced-encode-option lowpass_frequency=99

It'd be interesting to know if you can detect such differences on many/most tracks in your library, or just certain ones?

Well, I haven't ABXed the classical piece yet but from what the quick listen that I had they seem more difficult than the Prodigy tracks. I will try a quick ABX right away to see. The type of music that I listen to (Punk Rock, Metal, Blues) is usually quite easy to ABX (please don't tell me to ABX my whole collection, hehe). Regards.

Here is my ABX of the classical (ludwig piece). When I found out what to listen for it all got a lot easier but I found it out when I was doing the QT comparison which was the last on. I think Quicktimes low pass gave this one away. It was the violin at the end at the forte fizzo where the last percent/sustain of notes had clearly less high frequencies. Maybe I will try to ABX Nero again now when I know what to look for.

NeroAAC is still suffering from the bug I reported a while ago (I just downloaded the latest encoder from their site and ran the test at q=0.5 and 0.55):http://www.hydrogenaudio.org/forums/index....showtopic=83246 (http://www.hydrogenaudio.org/forums/index.php?showtopic=83246)

Unless they messed up the Quick Time encoder, it should encode the sample just fine.

Cymbal rides are used a lot in rock, metal, jazz, blues and whatnot and they get smeared by NeroAAC. You don't need to ridicule the guy for thinking it's inferior.

2) It is readily apparent that a member who agreed to our TOS made claims about quality on this forum without knowing about double-blind testing methodology. It doesn't matter if it the claims were correct or not, this is unacceptable.

I find QuickTime to be pretty weak against sharp transients, for example The Robot by Kraftwerk has lots of pre-echo on lower bitrates with QuickTime then with Nero AAC. Sometimes the pre-echo artifacts produced by QuickTime is just as bad as LAME's.

For example i just managed to ABX an random track at tvbr 90, due to smearing at 0:08:

It sounds fine to me at 90, but at 127 it has horrid pre-echo. Bitrates are similar aswell, the tvbr 90 encode is at 62kbps and the 127 encode is at 65kbps.

Two questions:1. Has this been reported to Apple as a bug (--I don't know if apple actually responds)?2. I assume this bug is only on the tvbr side--no such bug detected using cvbr at 256 (the itunes plus setting) or higher? (or does one need to use cbr to avoid it).

I also have a more general question, if this bug affects quicktime cVBR 320 and tVBR 127, but not quicktime CBR 320, would this suggest (when sticking with aac super-high bitrates) that CBR 320 is better as an archival format? Assuming no flaws, VBR should in principle always be better; but given that flaws exist, is there reason to think CBR would likely be safer, in these very high bitrate ranges? I know there have been at least a couple of instances before (of a VBR flaw not appearing in equivalent CBR, at moderately high bitrates) involving lame, but perhaps that's all there is to it.

If space doesn't matter to you, then yes, CBR 320 should be "safer" than VBR 320. You'll probably overcode a lot of tracks, but you can be relatively sure that nothing is undercoded. As I wrote in another thread, writing a good VBR algorithm is more complicated than one might think (danger of undercoding).

At 320 it doesn't matter whether you use MP3 or AAC. I prefer AAC for technical reasons (it was developed as an "advanced" version of MP3).

By the way, I ran some HA test items through iTunes 10.2, which was released yesterday, at 128 CVBR and got different results than for the latest 9.x iTunes version. Most notably, some pre-echos seem to have been solved, which should be interesting for /mnt, in particular.

I agree with Larson. Start with some ABX test of, say, 128 kbps. This might already be so close to transparency for you that it suffices. It certainly is for me for "casual listening" (for "serious listening" I use FLAC).

By the way, in a private blind MUSHRA test nero vs. iTunes which I ran last year at ~128 kbps VBR, iTunes won by a small but significant margin. So if you decide to use something near that bit rate, you should give iTunes 10.2 a try in order to get a "complete picture".

If space doesn't matter to you, then yes, CBR 320 should be "safer" than VBR 320. You'll probably overcode a lot of tracks, but you can be relatively sure that nothing is undercoded. As I wrote in another thread, writing a good VBR algorithm is more complicated than one might think (danger of undercoding).

Thank you, that's very helpful. This test result, where the higher vbr rate (the maximum!) is doing a lot worse than the lower vbr rate, opens one's eyes to some of the difficulties in vbr encoding. Also I'd venture to guess that at super-high bitrates VBR may not have offsetting advantages (that tvbr at max bitrate is increasing risk of glaring undercodes compared to cbr 320 while any vbr overshooting of the fixed cbr rate is without benefit at 320)--that's a different situation than 128 or 192 bitrates (where vbr could be "safer," i.e. less likely to produce glaring artifacts than cbr comparable bitrate range). (I know it largely defeats the purpose of lossy to use 320, but I want to stick with only one version of every piece in a good near universal format.) I wonder if aac cbr 320 has bested aac cbr 256 in any samples, but I assume, unlike tvbr, it will never be worse.

By the way, I ran some HA test items through iTunes 10.2, which was released yesterday, at 128 CVBR and got different results than for the latest 9.x iTunes version. Most notably, some pre-echos seem to have been solved, which should be interesting for /mnt, in particular.

I think 10.2 itunes, unlike 9.x, has the same quicktime as 10.1; both had qt 7.6.9--though 10.2 also shows "1680.9" which might be new. I don't know what quicktime /mnt or Steve Forte Rio used; it would be helpful to always post the version.

Have you been able to abx between aac cbr 320 and flac? (I'd assume you do it for other reasons; perhaps you're too aware of the "guts" of lossy codecs.)

By "serious listening" I simply meant listening to what I bought, which is CD audio. Having said that, yes, IIRC I was able to ABX either the eig sample or one of /mnt's Kraftwerk samples from here (http://www.hydrogenaudio.org/forums/index.php?showtopic=70598).

I am able to abx "some" of the stuff /nmt brings up here and there. I never were good at finding pre-echo samples.But it must be said that /nmt shouldn´t be a guide for anyone to adjust his settings to. I bet that many things /nmt finds to have problems is a non-issue for most human beings

But it must be said that /mnt shouldn´t be a guide for anyone to adjust his settings to. I bet that many things /mnt finds to have problems is a non-issue for most human beings :)

The concern in /mnt's finding is this:"It sounds fine to me at 90, but at 127 it has horrid pre-echo."The issue is not only that the artifact is very strong (horrid) to him, but especially that it is very strong at the max. vbr setting (127) while fine at a much lower setting (90)--with a caveat that I don't know if quicktime 7.6.9 was used. There are two standards: what I would detect (few if any artifacts) and what other people listening would detect in good conditions. The latter is hard to put a percentage on, but I'd like to have that also as close to zero as possible, while keeping only a "universal" file (i.e. aac or mp3). Under these circumstances, and where apparently bugs or less-than-perfectly-tuned algorithms still exist, CBR very high bitrate (256 or 320) might be safer than VBR (even vbr at equivalent bitrates). --For people who don't mind the hassle of multiple versions, of course keeping lossless and lossy versions is better.

I did some quick ABXing and I wasn't too impressed with Nero AAC. It performed a little bit worse than LAME (3.99) at the same bitrate/file size.

But I only tested with one sample, uploaded here (http://www.hydrogenaudio.org/forums/index.php?showtopic=89376) (the 'original' one).

I'm wondering if Quicktime AAC performs better, at least for this sample. I don't want to install Quicktime and learn all the settings, so could someone upload a properly encoded QT AAC version? I'm looking for a bitrate similar to that of V3, so I think the file size should be somewhere around 600-650 KB (I wouldn't mind multiple files of different sizes).

The file is smaller than I expected, but it looks like 3.98 produces slightly smaller (and IMO slightly worse sounding) files at V3 compared to 3.99, since with the latter the V3 conversion results in a 622KB file [for this sample].

That example is still somewhat easily ABXable to me, although I did get the impression that it's better than Nero AAC, considering the file size. So if you don't mind could you post an example of a slightly higher quality? Something around 650KB file size for that sample.

Thanks. I could still ABX that without too much difficulty. For a similar sized Nero AAC sample I used Q0.54 (~195kbps) in Foobar and got similar acoustic results. I can't honestly say I'd give a clear advantage to either.

LAME (3.99.3) seemed to perform better than both in terms of transparency. With V3 (which produced a slightly smaller file) I had more trouble ABXing.

It's only a short test with a single sample, so far from conclusive. I could also be biased since MP3 is a more convenient format for me (FolderPlay on my phone can't play AACs in MP4 files).

Thanks. I could still ABX that without too much difficulty. For a similar sized Nero AAC sample I used Q0.54 (~195kbps) in Foobar and got similar acoustic results. I can't honestly say I'd give a clear advantage to either.

LAME (3.99.3) seemed to perform better than both in terms of transparency. With V3 (which produced a slightly smaller file) I had more trouble ABXing.

It's only a short test with a single sample, so far from conclusive. I could also be biased since MP3 is a more convenient format for me (FolderPlay on my phone can't play AACs in MP4 files).