I'd welcome to have winamp's CT AAC encoder included.As a high anchor I guess Lame -V2 can be worse for some problem samples than a good AAC encoder @128 kbps. From previous discussion I thought lossless was to be the high anchor.

Right. Taking into account that test will have a high amount of difficult samples even AAC at 128 kbps won't be rated too high as to be compared to high anchor.

The following rules will be enough to avoid the use of high anchor:

CODE

Remove all listeners from analysis whoa) graded the reference lower than 4.5,b) graded the low anchor higher than all competitors.c) didn't grade the low anchor.

I thought I'd just pipe in and say I'm opposed to using Apple TVBR for the reasons already cited by others. No disrespect to nao, but I have a hard time understanding how easily his encoder slipped right into the mix.

EDIT: Does TVBR require QuickTime Pro? This would be another reason why I'd be opposed to TVBR.

I thought I'd just pipe in and say I'm opposed to using Apple TVBR for the reasons already cited by others. No disrespect to nao, but I have a hard time understanding how easily his encoder slipped right into the mix.

Poll resultsPoll was made before nao's post.Many people want to see TVBR even they aren't MAC users.

Yeah, I don't like it either. It takes 5 minutes (by the time track tag information is added) to encode one TVBR QuickTime AAC file under Windows using QuickTime Pro. Aside from nao's utility, QuickTime Pro is required for TVBR AAC encoding on Windows. I would have preferred CVBR simply because it is integrated into iTunes and is (in my opinion) easy to use. The masses want something else though so I can live with that. I still wish that it were included alongside QuickTime TVBR.

I agree. Since I have yet to see a blind test comparing CVBR and TVBR for multiple items, done my multiple people (if there is one, please point me to it!), why not include both in this test? Moreover, right now the poll is only slightly in favor of TVBR.

One thing I'm afraid that the difference between TVBR and CVBR are far less than between different encoders. People will have hard time to try to find any difference on T/CVBR instead of actually compare different encoders.

We can do poll and see but at least now I didn't find any sample where the difference between TVBR and CVBR was any pronounceable. If you find one let's know.

The effect of TVBR is mainly space saving at higher bitrates. You can use overkill quality settings comparable to iTunes Plus without wasting as much disk space. I don't think that there would be much difference at 128kbit/s. Still it would be interesting to see this verified. As C.R. Helmrich noted, there isn't much good data, yet.

Though not many people will be interested:Now that we got qtaacenc I just did a small listening test with harp40_1 and trumpet_myPrince which were the most problematic samples of 'mine' when used with Nero.--tvbr 65 and --cvbr 128 were both not transparent, and they also sounded pretty identical to me.--abr 128 wasn't transparent as well of course, but the result sounded better to me than the VBR results.I know many people think that only VBR is the way to go, true VBR if possible, but the variable bitrate method ABR can have its merits on its own when it's up to quality, not efficiency. It also uses high bitrate if necessary but obeys to another quality decision making process than does VBR.More interesting: AFAIK there was never a listening test ABR vs. VBR, at least not in recent years with up-to-date encoders. There's always just the widespread beleive that VBR is the best way to go qualitywise. I don't want to say that's wrong, but it would be fine to have this beleive verified in a test.

My suggestion: let's do a pre-test QT ABR vs. CVBR and use the best.(Of course that would bring the problem to also give the ABR way a chance for the other encoders who have this option in case ABR will be the winner, but a priori the situation that ABR should win against CVBR isn't what most people expect to happen. And if it should occur I think it's worth while thinking then about how to deal with the situation in the real test).

halb, I think we came back to specific options or versions of one competitor.Then we should give an opportunity to Nero's ABR or another version as well.We've reached to conclusion that only one version of Nero will be tested and untill now only VBR. (however I also find samples where Nero ABR perfoms better than VBR).

Then we should pre-test: Divx vs CT, Nero ABR(maybe even ABR+2pass), Nero VBR, Apple ABR, Apple CVBR and I don't want to mention Apple quality settings --normal vs --high. It's too much unless we can arrive to conclusion to discard some of those pre-tests.

I tend to propose to rely on developer suggestions as they know their codec better than any other one:

Nero VBR (the same as in previous public test)I've sent an e-mail to Apple developer and he said that VBR should be the best option.

However personally now after your mentions I'm interested to see ABR and VBR at least in my tests (and maybe in pre-test).

I understand your considerations, and part of them came to my mind as well when considering ABR.Anyway glad to hear that you encountered experience like mine and want to do a personal test or even the pre-test also with ABR.

Is it this?:iTunes uses CVBR and ABR, and for this reason you want to use iTunes' fixed quality setting which corresponds to qtaacens's --normal.As iTunes doesn't support TVBR you'd like to use --highest for TVBR.

As for 3. I'd like to see ABR in the test because CVBR results are expected to be more or less identical to those of TVBR. I guess optimum strategy however to keep everybody happy is to have a pretest ABR vs. CVBR.I'm not so happy comparing TVBR --highest against CVBR/ABR --normal, but I hope this doesn't change things a lot.

I've tried a few samples for ABX test on ABR vs TVBR vs CVBR and have found that ABR felt badly on Fatboy-like samples. The bitrate is extremely high for such killer samples and ABR is bitrate restricted on them.

I think we attribute too detailed attention just only to Apple encoder. It will be very hard to test all settings and modes for all encoders. We can't just test settings for Apple encoder without give same possibility to Nero.

For some good reasons Nero and Apple devs both suggest VBR. I don't think it's coincidence.

Remove all listeners from analysis who1. graded the reference lower than 4.52. graded the low anchor higher than all competitors.3. didn't grade the low anchor.4. didn't grade any of competitors.

Chris has suggested to change 1st rule to "graded the reference lower than 5.0" here

I tend to disagree.Imagine situation that there is codec A which has very noticeble artifacts on sample and ranked at pretty low score while codec B did a good job on lowpassing an old noisy record. Codec B could be ranked higher than reference lossless -> reference can be ranked lower than 5.0 as described in http://www.rarewares.org/rja/ListeningTest.pdf

Am I understanding correctly, that the constrained VBR setting in QT is more likely to be tested than the "constrained" iTunes VBR? I'd prefer iTunes because then the test would tell if using QT is worthwhile. (edit: ... i.e. if using QT tvbr instead of iTunes is worthwhile)

I could add the latest Nero and try to find a matching setting. Apparently the test is going to be a "128" test, or is "96" still a possibilty?

In general, does anyone have an opinion of which method should be used for checking the AAC bitrates? Should we blindly trust the applications that just read the header data? For instance, foobar and Mr QuestionMan don't always agree. Actually, apparently Mr Q. can't read QT tvbr files at all, but that can be fixed by retagging the files.