This is the invitation for a discussion about 48 Kbps AAC test, that should be done before the next 48 kbps multiformat listening test.

Gabriel from LAME development team and myself decided to organize this test - there are few reasons why this test should be organized, and why it should be organized before the next 48 kbps multiformat test:

My idea was to use combined sample set from multiformat 128 kbps listening test and previous Roberto's 64 kbps multiformat test - I thought of chosing several (5-6) samples from both of these two sets by using the worst scored samples.

Worst scored = Lowest average subjective difference grade (SDG) for all codecs in the particular set, except the low and (where applicable) high anchors.

Gabriel's addition was:

* 1 spoken (german male speech?)* 1 with strong L/R differences, in order to know how PS fares in bad conditions. Something like some old Beatles songs, with singer on 1 channel and instruments on the other one.

Sample selection is definitely open for further discussion here

When

Test should happen at the end of January - to make enough break after the current 128 kbps multiformat test.

Encoding Settings, Encoders, Bit Rates

Like with all other tests, we won't be testing closed or produced solutions - encoders used in the test will be widely available - as well as encoding settings and encoding material. Regarding the Coding Technologies' aacPlus encoder, my proposal is to use their imlpementation in the Winamp, which is widely available product.

Prior to the test, we will conduct public bit rate verification - in order to make sure codecs behave within the bitrate constraints.

The bitrates were examples, modify them to the 48kbps-range for direct relevance. For instance, it is possible that 40kbps VBR sounds better than 48kbps CBR and at the same time they require the same buffer.

And if everything above 48kbps skips, a buffer isn't used. And as has been said here earlier, it isn't reasonable to expect 56kbps modems to play 48kbps streams reliably. It can be done, but it isn't the scenario one would expect. When I had dial-up, I tried several times and failed 90% of the time.

Lastly, of course you can predict the upcoming bitrate; using some statistics on similar music, artists and masterings should give a reasonable estimate. But that wasn't what was questioned: The question was whether one could easily predict what buffer size would be needed. One way to do this would be to take the song with the highest average bitrate until now and use a buffer size which allows this song to be played smoothly. This isn't a good way to do it, but it is a way to do it, and shows that it is possible.