I think it'd be better to conduce an 128 kbps test once LAME 3.97 and Nero AAC are out.

I vote for WMA9 Pro and Sdt because:
1) Not the same codec
2) wma9 pro was never tested to 64 Kbps
3) hardware compatibility is not a problem : HE-AAC or MP3Pro are not compatible with hardware
4) wma9 sdt vs wma9 pro fight is very interessing

WMA9 Standard setting
I think that for very bitrate the best setting could be that:
cscript.exe wmcmd.vbs -a_codec WMA9STD -a_mode 4 -a_setting 64_44_2 -a_peakbitrate 96000 -a_peakbuffer 5000 -input C:\Audio -output C:\Audio

-> Max bitrate is 96 Kbps : lower variability
-> Max buffer = 5 sec : lower variability
In fact with these setting wma9 is between real VBR and real CBR and IMO it's better for overall quality at very low bitrate

WMA9 Pro sample
In theory it's impossible to make WMA9Pro with exact bitrate at 64Kbps (no profil for 64 Kbps target bitrate) but if you want I can make these encoding with exactly 64 Kbps for each sample in two pass mode.

It is not even meant to be used at 64kbps.



HE AAC is actually playable on some cell phones. And MP3pro is playable on several Thomson/RCA devices, among other brands.



It is not a fight. Not even Microsoft is interested in that fight! For them, WMA Std is the consumer codec, meant to be used for CDDA resolution at 64kbps. WMA Pro is the professional codec meant to be used at high resolutions, multichannel streams, at bitrates higher than 128kbps.



Settings tweaking IST EVUL.



There you go. WMA Pro is not meant to be encoded at 64kbps.

Beware of the bias of testing only killer samples. Comparing codecs on killer samples will only give you a hint on how they perform... on killer samples. Not on regular music. See here for a thread on the subject.

Not necessarily. You remember that many killer samples (in particular here in this thread) are only regular music. In other words, are situations of the real life. Tuning any encoder with "difficult parts of music" (killer samples) in order to do it more robust is the way as HA has managed to improve the performance of the encoders.

keep your ridiculous ideas on conducting listening tests to your own thread.


later

Heh, now this has become a fact?


I think that would be more interesting for everyone...

I bet the two encoders will be released right after my summer vaction is over. Hope not.

You might have LAME 3.97 beta before your vacation is over, but you'll hardly have final!

Would you test with a beta or a final?

Wise words from Roberto:

Ask the Developers opinion. That way, you save your face and don't get cornered in case everything blows up.

arghhhhhh ....
then 2 pass streaming mode with default setting : it's an usual mode in WMEnc
cscript.exe wmcmd.vbs -a_codec WMA9STD -a_mode 4 -a_setting 64_44_2 -input C:\Audio -output C:\Audio

default are:
- 1.5*bitrate for maxbitrate
- 3 sec for maxbuffer



In fact q10 quality is perhabs this mode ... but it's just impossible for you to obtain the good target bitrate for your specific samples tests ...

Pieroxy's ideas have nothing ridiculous. He was very clear: a listening test involving VBR and CBR encoders should include low-bitrate encodings, mid-bitrate encodings and high-bitrate encodings.
I'm quoting Pieroxy:


Now I'm quoting someone who's not used to post "ridiculous ideas" about listening tests, ff123:

=> Exactly the same "ridiculous" idea about the "ideal" test.

And ff123 followed:

Would you also say that ff123 has ridiculous ideas about listening test organisation? I'd really like to see that...



I posted the bitrate distribution curve of VBR encoders involved in my latest 80 kbps listening test:
http://foobar2000.net/divers/tests/2005.07...UTION_WMA80.png
http://foobar2000.net/divers/tests/2005.07...ION_aoTuV80.png

For both encoders, ~50% of the total samples were encoded with a bitrate lower to the targeted bitrate, and the ~50 remaining percent were encoded with a bitrate superior to the targeted bitrate. The distribution is close to the perfect curve for WMA and classical music (150 samples), with both mean and median at exactly 80 kbps. The curve is perfectible for aoTuV (median is 75 kbps), but distribution is also near-symetrical from both side of the median value.
It was maybe luck - I don't know - or maybe a consequence of the huge number of samples involved in my test (150+35) which maybe help to get a good distribution.