Detailed Agenda:1. Organization.People with experience of personal or public test are welcome here. Personally I can afford help for conduction of test. Unfortunately if I understand correctly that Sebastian informed that he donít want to conduct public tests.

2. Samples.Different styles of music, different levels of difficulty, pointing issues etc....? To be discussed here or in separate topic.

3. Codecs3.a) Multiformat test. 3.b) AAC test. I think that itís more appropriate to conduct AAC test because there are at least 3 AAC encoders to test. Nero, Apple and Coding Technologies/Dolby. All these codecs were updated during this year. More information in List of AAC encoders

4.Bitrates.96-100 kbits/s? It's possible to perform test at 128 kbits/s with very hard samples. Aemese-like samples will be very easy to spot from original.

IgorC: Yes, Fraunhofer's AAC encoder supports VBR coding. We don't distinguish between TVBR and CVBR, though, so that VBR mode is most likely a CVBR mode.

Sebastian: Maybe we should think about using a generic low anchor, as done in MUSHRA tests. How about a 7-kHz lowpass filtered version of the reference? Sonically, that should be quite similar to 48-kbps AAC LC. And we wouldn't have to worry about which encoder to choose for generating the anchor.

As mentioned in the AES Journal paper referenced here, the goal is to span the entire range of the grading scale with the codecs and anchors, in order to minimize bias, i.e. reduce the width of the confidence intervals. A 7-kHz anchor (and 48-kbps LC) should be about mid-way between "very bad quality" and the quality of the 96-kbps LC encoders. To define the lower end, we could throw in 8-kHz 8-bit a-Law PCM of the reference as "64-kbps phone quality low anchor". That will take very little listening effort to identify, so it doesn't make the test more difficult, but gives us the advantage of stabilizing the test results.