Resampling is a different ballgame -- I'd pre-resample the samples with ssrc if resampling is going to be a factor. Oggenc's built-in resampling, for example, is terrible, while on the flip-side I find that a ssrc'd 45kpbs 22khz vorbis file with the lowpass lifted will very usually sound rather better (and have fewer killer artifacts) than a 45kpbs 44.1khz vorbis file (personal, double-blinded, very conspicuous). 80kbps+ might be a different matter, where I don't venture much.

Edit: BTW, what else do we need to make the merged 1.1.1+b4 version the recommended one?

Probably additional listening tests, or maybe calling into question the way recommendations are done.

I'm open to suggestions. In the beginning, we didn't even have a recommended vorbis encoder thread, so I put one together very quickly at the time. Now that vorbis quality is starting to take some of the limelight, I think it is time to work out a systematic way of doing this.

I'm open to suggestions. In the beginning, we didn't even have a recommended vorbis encoder thread, so I put one together very quickly at the time. Now that vorbis quality is starting to take some of the limelight, I think it is time to work out a systematic way of doing this.

I honestly think there should also be page for it in the wiki to as well as the thread. The thread has had a significant impact though and applaud you for taking the time to put it together. What's important is that these changes in the encoder should merged into the next official Vorbis branch much like 1.1. That should first and foremost remain recommended encoder. All of the other binares should remain around here though for people who are interested in the latest bleeding edge changes or seeking an alternative

(...) or maybe calling into question the way recommendations are done.

I'm open to suggestions. In the beginning, we didn't even have a recommended vorbis encoder thread (...)

I suggest that we (note that I say "we" and not "you") don't recommend any specific encoder. There are many possible reasons to not recommend a specific encoder, but the less acceptable one is the one linked to the lack of listening tests. We have the chance to have people working hours and hours to improve the quality of an encoder (it's not necessary the case), and we can't tell them "bravo, but sorry we don't have any feedback to recommend your work".If the community can't spent one hour of free time to make a listening test, the community don't have the right to give recommendation based on missing knowledge. It's just a sign of respect and the minimum we can do for the creative and innovative persons working for thousands or even millions people.

The recommendation should therefore be limited to explain the use of the encoder:• why users shouldn't tweak the default profiles• how people could solve some issue (pre-echo with --ITP as example)• explain all known problems with the encoder (specific artifacts)• why VBR and not ABR; tips to avoid playback problems with some flash players....

There's no need to recommend an encoder, especially older one over newer and not-tested ones (I don't like the expression "non-tested": it supposes that developers are throwing their work to the public without bother to test it themsleves — and it also supposes that the lack of report is a sign of lack of tests; I'd rather say: no news = good news ).Couldn't we simply precise that:

• 1.1.1 is the latest CVS version, that quality is essentially based on the work performed by Aoyumi for aoTuVb2, and that this version is obviously not the most advanced version of vorbis?• aoTuV b4 is the latest version, and that this encoder solves x, y and z issues or bug, and consequently should offer the best results?• there are also other encoders, {slightly} outdated now, like GT2/GT3, Megamix, QK, ModestTuning and give of short description of them?

I know that people like and request explicit answers to their problem: they want THE best encoder and THE transparent setting. As someone starting to have a good experience of multi-codec/multi-format blind listening comparisons, I can say that such encoders and such settings don't and probably won't exist. aoTuV b4, lame 3.97, Nero AAC... could outperform all their competitors, there are still problematic samples for them, some problems audible with the most advanced encoders but not audible with less recommendable encoders.

You can still say one encoder is preferable over the other for the majority of uses and the majority of genres. Just like you can say a certain bitrate is transparent to the majority of people on the majority of samples. Everyone with some knowledge will know such recommendations aren't absolute. Everyone else will be happy to follow them and feel assured they're getting the best out of Vorbis. Not recommending one but instead point out how the encoders should be used and the relative differences between them will, even if it is more correct, only be seen as vague.

I beleive keeping things simple for the average user, with one encoder to use, and no more settings than the bitrate, will help spread Vorbis more than the posibility of the recomendations being incorrect will hold it back.

I'm relatively new to this forum and things like ABX'ing, but if someone organises a testing effort for aoTuV b4 i'd be happy to participate. If for nothing else, just because Aoyumi deserves to see some community response to his work.

If this is a discussion on principles, it is not an easy one. I have few answers, but a lot of questions...

Is it not a recommandtation to precise that encoder N solves x, y and z issues or bug, and consequently should offer the best result? Is it OK to do this without comparitive testings to back it up? Isn't the fact that there will be more or less problematic samples for any encoder an argument to perform testings on different types of music and compare to other/older encoders - and would this be a sign of disrespect of developers or a sign of conservative thoroughness?

I agree that there is a good idea to have some kind of factbox on each encoder, almost like it has been done for lossless encoders. Unlike lossless encoders, where sound quality is pr def 100% for all the encoders, sound quality would be the key factor to distinguish between good and less good lossy encoders - would it be possible to show sound quality in a factbox? The problem will be how much one should to rely on theoretical improvements vs tested/verified improvements. To much emphasis on the latter can result in few users of an superior encoder (because of the waiting for test results), and to much emphasis on the first can lead to the embracement of an encoder which can't handle real life...

Mercedes-Benz launched their A-series some years ago, and they were very pleased with their development process. They had cut down on expensive real-life-testing, and instead used more computer simulation etc - problems arose when a swedish magazine performed the so-called "moose-test", in wich the car should do a fast manouvre to avoid crashing into a moose on the road. The manouvre resulted in a car up side down . Not just once or twice, it was more of a rule than an exception. Basically - (insufficient) theory was beaten by reality...

The choice of this analogy may be an indication of where I'm heading - I don't know yet...