Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: LAME development and default settings (Read 39142 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

LAME development and default settings

I'm a bit confused why Gabriel recommends to use "--vbr-new" yet he refused to make it default in the beta. The same with "--athaa-sensitivity 1". It might improve the quality, but if we use that, we won't know the quality of the default behaviour that most people use. And I know Guru prefers those two, but he is only one person, plus his genre preference is not exactly "common".

Oh, and I think the test should be open for at least a month. 12 days are not long enough IMO.

LAME development and default settings

Reply #1 –
Quote
I'm a bit confused why Gabriel recommends to use "--vbr-new" yet he refused to make it default in the beta. The same with "--athaa-sensitivity 1". It might improve the quality, but if we use that, we won't know the quality of the default behaviour that most people use. And I know Guru prefers those two, but he is only one person, plus his genre preference is not exactly "common".

Oh, and I think the test should be open for at least a month. 12 days are not long enough IMO.
[a href="index.php?act=findpost&pid=343237"][{POST_SNAPBACK}][/a]


I agree with all of those points.  I posted my thoughts on the "--vbr-new" switch (and it not being default) already in another thread so I won't bother to repeat them.

What's a bit interesting about this test -- and guruboolez actually pointed this out to a degree in his posts -- is that a lot of people are clamoring about popularity, but then some of the codecs being used, and especially some of the configurations they are being used in, are certainly not at all popular.  Meanwhile, popularity has been used to discount at least 3 different codecs from being included in the test.

Seems a little bit inconsistent...

LAME development and default settings

Reply #2 –
Quote
And I know Guru prefers those two, but he is only one person, plus his genre preference is not exactly "common".
[{POST_SNAPBACK}][/a]

1/ My preference for --vbr-new was established during the different lame alphas thread. I used samples galleries coming from different listening tests; in other words: not only classical.
2/ I'm not alone in this case: see [a href="http://www.hydrogenaudio.org/forums/index.php?showtopic=35905&view=findpost&p=316811]Bug80[/url] listening test.
3/ --athaa-sensitivity benefit was discovered long time before I knew and used it. Ask Dev0 or [proxima]. I don't think that Corelli and Bruckner are their favorite composers.

LAME development and default settings

Reply #4 –
Gabriel (or Robert? maybe both... I can't remember) already answered. --vbr-new is not the default VBR mode because the quality impact is still unknown when applied with the lowest VBR mode. That's why the beta 1 of 3.97 still use the previous VBR mode as default.
For the final version, I'm not sure but it seems that --vbr-new has real chance to replace the current mode.

LAME development and default settings

Reply #5 –
Quote
Gabriel (or Robert? maybe both... I can't remember) already answered. --vbr-new is not the default VBR mode because the quality impact is still unknown when applied with the lowest VBR mode. That's why the beta 1 of 3.97 still use the previous VBR mode as default.
For the final version, I'm not sure but it seems that --vbr-new has real chance to replace the current mode.
[a href="index.php?act=findpost&pid=343374"][{POST_SNAPBACK}][/a]


It seems to me that it would be less confusing then if they defaulted vbr-new at the levels it has been tested well at and confirmed to be good, and left vbr-old on at lower levels.  This is quite a trivial thing to enforce in the encoder, and seems to me to be a much better policy than changing the recommending settings to a state that encourages people to start using psymodel affecting flags again.

For all those who probably remember the state of LAME usage before the focus on presets and recommended settings, I'm surprised there isn't more concern about this.

LAME development and default settings

Reply #6 –
Quote
I'm a bit confused why Gabriel recommends to use "--vbr-new" yet he refused to make it default in the beta. The same with "--athaa-sensitivity 1". It might improve the quality, but if we use that, we won't know the quality of the default behaviour that most people use.

Vbr-new is not defaulted because defaulting it would require too much delay before the release. Such a change would require several monthes of real life testing. This is not a problem related to the quality of the encoding mode, but due to the behavior of the encoder while used by third party applications.
However, recommending vbr-new is not different than recommending to use FhG encoders in standard/slow/fast modes or to use Nero encoder in fast/high modes. It seems to not be a problem for people here to use a non-defaut encoding mode for those  encoders, but seems problematic for Lame. I am wondering why?
This is not a switch to tweak psymodel, but simply a switch to select encoding engine.

Using vbr-new is my recommendation, as a Lame developper. I am free to recommand whatever I want when asked. If this is not in the focus of HA, I do not see any problem, as HA recommendation is not the same as my recommandation. You have to choose in the context of a listening test if you want to follow HA recommandation or developpers recommandation.

Regarding the --athaa-sensitivity switch, I know this would improve quality with high dynamic tracks. However, this is mainly a kludge involving psy model tweaks. IMHO this should be handled by Lame itself and not by the end-user. That is why this switch is not recommended by me, and not available in standard builds. If in the context of those tracks Lame produces non-optimal encodings, then it is my fault and I am assuming it, but I will not recommand to use for a listening test a switch not available to end users. I would consider this to be cheating.
 

LAME development and default settings

Reply #7 –
Quote
This is not a problem related to the quality of the encoding mode, but due to the behavior of the encoder while used by third party applications.


Such as?  I'm not sure I quite understand what you mean here, unless you are referring to the possibility of certain players not handling the tracks properly, but I don't see how this would be a problem for compliant decoders exactly.

Quote
However, recommending vbr-new is not different than recommending to use FhG encoders in standard/slow/fast modes or to use Nero encoder in fast/high modes. It seems to not be a problem for people here to use a non-defaut encoding mode for those  encoders, but seems problematic for Lame. I am wondering why?


I've never been too big of a fan of these distinctions when it's possible to avoid them, but there's a few key differences that are worth point out.

In a fast vs. slow mode, or in a high quality vs. low quality mode, you know exactly what you are getting, assuming that the description is correct.  With vbr-new vs. vbr-old, you have no idea at all what you are getting except that one version is new and one is old.  What exactly does that mean?  Will the average user understand the difference between the two?

The fact that there are two different modes available, one of which is recommended but not defaulted, is confusing to users I think, especially since it's unclear as to why the new mode would be better unless you do some extra research.

Quote
This is not a switch to tweak psymodel, but simply a switch to select encoding engine.
  You're right, I should have been more explicit -- I was also referring to --athaa-sensitivity when I made that statement though.

Quote
Using vbr-new is my recommendation, as a Lame developper. I am free to recommand whatever I want when asked. If this is not in the focus of HA, I do not see any problem, as HA recommendation is not the same as my recommandation. You have to choose in the context of a listening test if you want to follow HA recommandation or developpers recommandation.


Sure, but I don't see why there should need to be big conceptual difference between recommendations.  And AFAIK, you participated in changing the current HA recommendation through the discussions.  I don't think anyone is saying you shouldn't recommend whatever because it's not up to HA standards or something, but at the same time, as a LAME developer with influence, some of us might wonder about certain recommendations a bit more if they come from you than from someone else.

Quote
Regarding the --athaa-sensitivity switch, I know this would improve quality with high dynamic tracks. However, this is mainly a kludge involving psy model tweaks. IMHO this should be handled by Lame itself and not by the end-user. That is why this switch is not recommended by me, and not available in standard builds. If in the context of those tracks Lame produces non-optimal encodings, then it is my fault and I am assuming it, but I will not recommand to use for a listening test a switch not available to end users. I would consider this to be cheating.
[a href="index.php?act=findpost&pid=343386"][{POST_SNAPBACK}][/a]


I agree with this part.  Especially since people are focusing so much on popularity, it makes less and less sense to use an obscure and unrepresentative configuration of the encoder to test -- the results aren't going to be analogous to popular performance of the codec in such a case.

LAME development and default settings

Reply #8 –
Quote
Using vbr-new is my recommendation, as a Lame developper. I am free to recommand whatever I want when asked. If this is not in the focus of HA, I do not see any problem, as HA recommendation is not the same as my recommandation. You have to choose in the context of a listening test if you want to follow HA recommandation or developpers recommandation.
[a href="index.php?act=findpost&pid=343386"][{POST_SNAPBACK}][/a]


And this is exactly why I asked the developers what settings they recommend.

If we were about popular settings, we'd be using everything at CBR 128 kbps. The reason I am claiming this is because most of the people I talk to in other forums don't even know what VBR is and what it's good for.

Also, when using settings recommended by the developers, it's almost impossible to attack claiming that sub-optimal settings were used.

LAME development and default settings

Reply #9 –
Quote
Quote
Using vbr-new is my recommendation, as a Lame developper. I am free to recommand whatever I want when asked. If this is not in the focus of HA, I do not see any problem, as HA recommendation is not the same as my recommandation. You have to choose in the context of a listening test if you want to follow HA recommandation or developpers recommandation.
[{POST_SNAPBACK}][/a]


And this is exactly why I asked the developers what settings they recommend.

If we were about popular settings, we'd be using everything at CBR 128 kbps. The reason I am claiming this is because most of the people I talk to in other forums don't even know what VBR is and what it's good for.

Also, when using settings recommended by the developers, it's almost impossible to attack claiming that sub-optimal settings were used.
[a href="index.php?act=findpost&pid=343394"][{POST_SNAPBACK}][/a]

No, that's just inconsisten behaviour. The LAME developers decide the default settings LAME uses for encoding, yet for some reason they recommend using nondefault settings for a listening test. As an user looking from the outside, that just doesn't make sense to me.

Btw Alex B, you are using an outdated version of MrQ, you can get the latest here:
[a href="http://www.burrrn.net/download/MrQuestionMan.exe]http://www.burrrn.net/download/MrQuestionMan.exe[/url]

LAME development and default settings

Reply #10 –
Quote
Quote
Quote
Using vbr-new is my recommendation, as a Lame developper. I am free to recommand whatever I want when asked. If this is not in the focus of HA, I do not see any problem, as HA recommendation is not the same as my recommandation. You have to choose in the context of a listening test if you want to follow HA recommandation or developpers recommandation.
[{POST_SNAPBACK}][/a]


And this is exactly why I asked the developers what settings they recommend.

If we were about popular settings, we'd be using everything at CBR 128 kbps. The reason I am claiming this is because most of the people I talk to in other forums don't even know what VBR is and what it's good for.

Also, when using settings recommended by the developers, it's almost impossible to attack claiming that sub-optimal settings were used.
[a href="index.php?act=findpost&pid=343394"][{POST_SNAPBACK}][/a]

No, that's just inconsisten behaviour. The LAME developers decide the default settings LAME uses for encoding, yet for some reason they recommend using nondefault settings for a listening test. As an user looking from the outside, that just doesn't make sense to me.

Btw Alex B, you are using an outdated version of MrQ, you can get the latest here:
[a href="http://www.burrrn.net/download/MrQuestionMan.exe]http://www.burrrn.net/download/MrQuestionMan.exe[/url]
[a href="index.php?act=findpost&pid=343396"][{POST_SNAPBACK}][/a]


And didn't Darin, Gabriel, etc. use listening test results to implement stuff into the default settings?
In one of Roberto's tests --athaa-sensitivity 1 was used although it was not a default setting. So what? People can use it. It's not something hidden whatsoever.

LAME development and default settings

Reply #11 –
Quote
In one of Roberto's tests --athaa-sensitivity 1 was used although it was not a default setting. So what? People can use it. It's not something hidden whatsoever.
[a href="index.php?act=findpost&pid=343399"][{POST_SNAPBACK}][/a]

Of course, but a lot of efforts have been made in recent years to get rid of all those commandline tweakings. I just don't want to see those times coming back.

LAME development and default settings

Reply #12 –
Quote
I want to know what encoder gives me the highest quality when I encode my CD to 128kbps.
(...)
Using special tweakings to encode the samples could be considered cheating from that point of view.
[a href="index.php?act=findpost&pid=343408"][{POST_SNAPBACK}][/a]

It looks paradoxical to me.

BTW, Gabriel explained why changes can't be immediate for LAME. This encoder is widely used by end-users, commercial softwares and the output files are supposed to be readable on more than 10.000 portable, DVD, and video games players. They can't take the risk to partially break the compatibility by changes that marginally affect the quality.

The users of lossy encoders are divided in two different categories: informed users (looking for the best tools and sometimes using commandline encoders and exotic switchs) and carefree ones. We perfectly know that collective listening tests are only useful for the first category of people. That's why it's perfectly acceptable to use what we could call exotic encoders. For one aoTuV beta 4 user, how many hundreds are using plain vanilla CVS one? And for one LAME 3.97b1 VBR@130 kbps music-lover, how many millions are using the encoder used in the first CD ripping tool provided by a friend or the driver CD offered with the last birthday present? Should we discard these encoders because they're not popular at all? And if not, why should we apply a different logical for the command lines? We're all looking for optimal encodings, and most of us don't care to use suboptimal ones.

I fully agree with Sebastian Mares attitude, and to follow the developers recommandation. If Aoyumi is agree to use beta 4.51, then go with aoTuV 4.51 (unless someone find big issues with this last beta). If Gabriel is agree to use --vbr-new and not --athaa-sensitivity 1, then go for -V5 --vbr-new (I personaly regret that --athaa-sensitivity 1 won't be used for a second time, but Gabriel explained why).

We can't seriously follow the "popularity criterion" without making a strong survey about popular choice. We're not even sure that iTunes VBR is now more popular than iTunes CBR.

LAME development and default settings

Reply #13 –
If someone wants to discuss about Lame default settings, please start another thread, as this is not really relevant to this listening test.

LAME development and default settings

Reply #14 –
Quote
so we all know at least V2 --vbr-new will be an improvement on 80% or so of all mp3 players out there..
[a href="index.php?act=findpost&pid=343419"][{POST_SNAPBACK}][/a]

I may be wrong, but I suppose that all possible problems lay on third-party software. Previous example was --r3mix: a lot of users asked to lame developers to remove this outdated preset, but doing this could introduce bug or crashes on application offering --r3mix option. That's why --3mix is still present (and now remaped to -V3 --vbr-new), but this persistent presence doesn't mean that lame developers are recommending it.

LAME development and default settings

Reply #15 –
Quote
No, that's just inconsisten behaviour. The LAME developers decide the default settings LAME uses for encoding, yet for some reason they recommend using nondefault settings for a listening test. As an user looking from the outside, that just doesn't make sense to me.

for me it looks like they are being a little more carefull for the general public, but that they are confident enought about the new quality that they want it test it. if we never ever test it like this, how can they be sure it is really better then?

Quote
Quote
And as far as popularity is concerned, I'm confident the combination MD player + ATRAC is more popular than aoTuV Vorbis or Nero AAC on any other portable device.
[a href="index.php?act=findpost&pid=343312"][{POST_SNAPBACK}][/a]

I also agree with you. That's why I considered as "ambiguous" the choice of popularity as criterion for this test. It becomes easy to object the choice of aoTuV as vorbis encoder; LAME is surely popular but 3.97b1 surely less (Winamp devs are waiting for a final version for example and are keeping in the meantime 3.96.1) and -V5 --vbr-new probably not.

vorbis is important because: 1) is the only patent free encoder and 2) is the other only codedc, besides MP3, AAC and WMA, that is being push by many comercial comapnies. MD is being fased out even by Sony.

LAME development and default settings

Reply #16 –
This is getting ridiculous and I'm getting frustrated...

Quote
BTW, Gabriel explained why changes can't be immediate for LAME. This encoder is widely used by end-users, commercial softwares and the output files are supposed to be readable on more than 10.000 portable, DVD, and video games players. They can't take the risk to partially break the compatibility by changes that marginally affect the quality.
[a href="index.php?act=findpost&pid=343410"][{POST_SNAPBACK}][/a]

Break compatibility? That has nothing to do with this, we are not breaking compatibility with those switches.

Quote
Quote
so we all know at least V2 --vbr-new will be an improvement on 80% or so of all mp3 players out there..
[a href="index.php?act=findpost&pid=343419"][{POST_SNAPBACK}][/a]

I may be wrong, but I suppose that all possible problems lay on third-party software. Previous example was --r3mix: a lot of users asked to lame developers to remove this outdated preset, but doing this could introduce bug or crashes on application offering --r3mix option. That's why --3mix is still present (and now remaped to -V3 --vbr-new), but this persistent presence doesn't mean that lame developers are recommending it.
[a href="index.php?act=findpost&pid=343424"][{POST_SNAPBACK}][/a]

This is a completely different issue, you're mixing up backend compatibility issues with quality and format compatibility issues.

Quote
I fully agree with Sebastian Mares attitude, and to follow the developers recommandation. If Aoyumi is agree to use beta 4.51, then go with aoTuV 4.51 (unless someone find big issues with this last beta). If Gabriel is agree to use --vbr-new and not --athaa-sensitivity 1, then go for -V5 --vbr-new (I personaly regret that --athaa-sensitivity 1 won't be used for a second time, but Gabriel explained why).
[a href="index.php?act=findpost&pid=343410"][{POST_SNAPBACK}][/a]

OK, let me put it like this:
We used "--athaa-sensitivity 1" in the previous test. This setting has since not been defaulted. As a result, pretty much nobody uses it for their encodes. So basically, we tested an encoding setting that nobody uses. That's ridiculous. For real world usage, the results from the previous test are absolutely worthless.

LAME development and default settings

Reply #17 –
Quote
What I don't understand is that Gabriel recommends to use --vbr-new, but says that --athaa-sensivita 1 should not be used by the user, but should be something that the encoder handles; shouldn't the encoder handle --vbr-new, too?
That's why I think if --athaa-sensivity 1 provides better results, it should be used.
[a href="index.php?act=findpost&pid=343512"][{POST_SNAPBACK}][/a]

This is EXACTLY the problem. Those decisions are to be made by the developers, not the users. The user should not have to tweak around with switches. Dibrom started the revolution some three years ago, and it's sad to see that LAME still has to deal with those issues. You don't see the iTunes encoder having those abstruse options, yet it's the (arguably) best encoder available. And the simplicity is definitely a part of the success.

LAME development and default settings

Reply #18 –
Quote
This is a completely different issue, you're mixing up backend compatibility issues with quality and format compatibility issues.
[a href="index.php?act=findpost&pid=343538"][{POST_SNAPBACK}][/a]

I don't think so.

Quote
OK, let me put it like this:
We used "--athaa-sensitivity 1" in the previous test. This setting has since not been defaulted. As a result, pretty much nobody uses it for their encodes. So basically, we tested an encoding setting that nobody uses. That's ridiculous. For real world usage, the results from the previous test are absolutely worthless.


And? All collective tests are quickly outdated, because selected encoder are often quickly replaced by others. Does it mean that results automatically become worthless? I don't think so. People are still using them as reference.

Second point: if people are using a different commandline from the one which was tested, then blame these people. You're free to use or not the tested command line. As well as you're free to use or not the same encoder. "Real world usage" has few things to do with these tests. Most people on earth, inluding lame users, are not using VBR with MP3 at this bitrate. -V5 is in the same situation as -V5 --athaa-sensitivity 1: few people only uses them.

Third point: I also recall that popularity or real life usage is not necessary a target of these tests. Several encoders were used in the past which were totally irrelevant for people: the highly-expensive Sorenson AAC encoder, the ultra-expensive Audioactive encoder, the very expensive Audition MP3. People didn't complain about irrelevancy. Why? Because these tests are intended for curiosity, and to get answers about usual question (which encoder is the best).
If we have tested encoders that cost $2000 that nobody on this board could afford, I don't see why we shouldn't discard encoding choice which only require from people to add a small commandline (--vbr-new and/or athaa...) to benefit from full quality. And currently, it seems that the best encoding method for 130...135 kbps MP3 encoding is neither -V5 nor -V5 --vbr-new, but -V5 --vbr-new --athaa-sensitivity 1, which is perfectly suitable for real life usage: it only depends to users to set it properly and to make it something popular. Listening tests precede popularity and sometimes real life usage, not the opposite.

LAME development and default settings

Reply #19 –
Quote
This is EXACTLY the problem. Those decisions are to be made by the developers, not the users. The user should not have to tweak around with switches. Dibrom started the revolution some three years ago, and it's sad to see that LAME still has to deal with those issues.
[a href="index.php?act=findpost&pid=343544"][{POST_SNAPBACK}][/a]

I recall for your own enlightment that the current situation didn't get worse, since. It's rather the contrary because situation has clearly progressed.
Do you remember --alt-preset standard/extreme -Z? Do you remember the -Y hack used because -V3 and -V4 weren't trustable when people requested for lower bitrate? These experimental switchs were even present in the recommendation! Nowadays, the recommandation don't talk about any additional switch. There are only users, like me, and after rigorous listenining tests, which are drawing attention to current flaws and to unrecommended but working switchs.

Quote
You don't see the iTunes encoder having those abstruse options, yet it's the (arguably) best encoder available. And the simplicity is definitely a part of the success.

We're talking about quality, not success. And LAME developers are clearly not to blame: they make very clear their desires to see simple configuration frontend to their encoder:



Isn't it enough?

LAME development and default settings

Reply #20 –
I thought that the purpose of this thread was to determine which encoder would be featured in the upcoming test and which settings would be used.

A few people seems to think that this thread is about what developpers should do with their encoders.
If you want to start such a discussion, please start another thread. As this specific subject is likely to degenerate into flamming, as usual, it will ease moderators job.

LAME development and default settings

Reply #21 –
Quote
I thought that the purpose of this thread was to determine which encoder would be featured in the upcoming test and which settings would be used.


It is.

Quote
A few people seems to think that this thread is about what developpers should do with their encoders.


I think discussion about default LAME settings is highly relevant to the rest of this discussion because the status of default settings has a direct impact on whether or not certain encoder configurations used in the test will provide representative results.

Quote
If you want to start such a discussion, please start another thread. As this specific subject is likely to degenerate into flamming, as usual, it will ease moderators job.
[a href="index.php?act=findpost&pid=343561"][{POST_SNAPBACK}][/a]


So far I haven't seen any flaming.  I am starting to see some people (as usual) take criticism personally though.  If anything, this is what will lead to flaming.

LAME development and default settings

Reply #22 –
Quote
I thought that the purpose of this thread was to determine which encoder would be featured in the upcoming test and which settings would be used.

A few people seems to think that this thread is about what developpers should do with their encoders.
If you want to start such a discussion, please start another thread. As this specific subject is likely to degenerate into flamming, as usual, it will ease moderators job.
[a href="index.php?act=findpost&pid=343561"][{POST_SNAPBACK}][/a]

We can always split the discussion to a separate thread. But that doesn't take away from the problem that exists.

LAME development and default settings

Reply #23 –
Quote
Do you remember --alt-preset standard/extreme -Z? Do you remember the -Y hack used because -V3 and -V4 weren't trustable when people requested for lower bitrate? These experimental switchs were even present in the recommendation!


If you'll remember, I didn't want these switches to be used.  But by the time problems were apparent, I wasn't actively working on LAME anymore.  And eventually, IIRC, at least -Z was folded into the presets anyway (as they should).

Quote
Nowadays, the recommandation don't talk about any additional switch. There are only users, like me, and after rigorous listenining tests, which are drawing attention to current flaws and to unrecommended but working switchs.


This is a development issue.  If there were not so many possibilities for internal reconfiguration, those switches would not need to be tested.  That they are is the result of not managing encoding engine complexity at the time improvements were made -- i.e., determining at development time whether or not an addition is to be defaulted and made to replace the old behavior, instead of constantly adding more and more and changing nothing.

Quote
We're talking about quality, not success. And LAME developers are clearly not to blame: they make very clear their desires to see simple configuration frontend to their encoder:

Isn't it enough?
[a href="index.php?act=findpost&pid=343550"][{POST_SNAPBACK}][/a]


I'm curious -- if a program does not work in an ideal fashion, then who is to blame if not the developers?  Now, I don't want to turn this into a flame war, especially after my response to Gabriel.  But the LAME developers are the only ones who have ever had control over the LAME frontend or the rest of the program behavior.  Maybe they want things simple now, but nobody but them allowed things to get out of control (and still that way to a more limited extent) in the first place.

The point of all of this really should be whether or not we are going to include certain configurations in this listening test.  I'm perfectly OK with including obscure stuff, but if that's the case, Sebastian really needs to clarify the point of this test, because most of the stated reasons are totally inconsistent with this approach.  Of course, nobody has to explain or justify anything if they don't want to.

LAME development and default settings

Reply #24 –
Quote
I think discussion about default LAME settings is highly relevant to the rest of this discussion because the status of default settings has a direct impact on whether or not certain encoder configurations used in the test will provide representative results.
[a href="index.php?act=findpost&pid=343563"][{POST_SNAPBACK}][/a]

Representative of what? of who?
If ever Vorbis is used at -q4,15 (or something like that), would it be a representative setting? Is aoTuV beta 4.51 representative of anything? This encoder may be replaced by an updated one few times after the test, and if it occurs, the test will also stop to be representative.

Again, the featured encoder and settings were and are not selected because they are representative, popular, friendly or whatever else. But because they're considered either as better than anything else or safer than untested commands. What most people are currently using, or what some other people are currently recommending were never considered as important for previous tests. Because what most people are using is often unefficient and because recommendations are often behind one's time. It's very clear that Sebastian is looking for the most advanced encoder, not the most popular one. He also tries to maximies the quality for all of them, and this go against all popularity or representativity considerations.