Unreasonable choice by Elsevier. I never understood why the authors of a University/Institute have to pay for open access on top of the huge subscription bill.
I recognize that I only have read the last post and had searched in the past for royalty information about CRAM and never found it. Thanks for your answer.
In my opinion, there is clearly the need to assess both solutions with clear and meaningful data, not only in terms of performance but also in terms of patents. Conferences are a great place to do it and thus, I completely agree with you.
However, I don't see an MPEG standard as evil (or ugly) and I do think that both types of standards (CRAM and MPEG) can coexist. Every company should decide (based on factual information) what is the best solution for their needs and if the MPEG standard brings some advantage, a company may use it despite the licensing costs. The same happens for video coding standards, where the patent heavy HEVC is nowadays used in some scenarios (e.g. iPhone) and the royalty free AOM AV1 is used in others (e.g. streaming video). It is up to the market" to decide. The main problem with MPEG-G is that the licensing information is not known yet since it didn't reach draft international standard yet.
All MPEG standards have patents and this one is not an exception. If companies are interested they can license its use (assuming fair terms). This is far better than having proprietary formats which are locked or formats made by a single company which you don't know the patent situation clearly. Also, companies involved invested in the development of this standard and expect some return.
What I don't like in this post, is the call for non-adoption when the author has a competing format (CRAM) for which the patent situation and the performance is not clear. It seems a biased opinion.
Note that they are speaking about encoding complexity. The point is that decoder complexity increases are also needed (although, not as much !) and every time that encoder complexity has increased in the past, decoder complexity also grew.
The really interesting question is how much decoder complexity increase is acceptable.
Better yet is to design an arithmetic encoder that models the state probabilities accordingly. Also, the state of the game should be refreshed periodically by compressing it without XORing, otherwise, when packet losses occur you may have losses or unacceptable delays.
I have used it to teach an introductory course in computer networking and it could perform well many net protocols (DHCP, NAT, etc.) and even some advanced routing configurations (with RIP/OSPF).
UI was a little rough on the edges but after a while you get used to.