There are still progress in compression algorithms today, so I wouldn't exclude better compression as an option, would be nice to have hardware compression (general, obviously GPU already support compressed data) to save time too but I wouldn't count on it.
Do you genuinely believe that better compression will get 50 GB games down onto 9 GBs? And moreso, that console games won't use these compression systems as well to fit more in?
1) Maybe. So they won't be an issue. Some still do (Quantum Break anyone?). It's good to have a solution.
You're talking about getting 50 GB games onto a 10 GB footprint or something - enough that a lack og BR drive and HDD won't hurt Swtich. If the current game file sizes aren't due to video, then there's nothing to be gained from using alternative video compression.
2) Textures were used differently back then. Most of the time one texture => one file or one memory chunk. Now we have mega textures, i.e. one image that contains all or most of the textures. Much better suited for compression and much bigger gains to be had.
Hardly anyone is using megatexturing. And megatexturing creates
huge files. Everyone else is using compressed texture maps handled in hardware. There's very little savings to be gained in texture compression by new techniques.
4) Use Ogg Vorbis instead. ADPCM is awful.
All games use compressed audio by and large. Again, virtually no savings to be had.
World data: Without changing data: Use something better than zlib compression (e.g. LZMA2). Compression rates can vary greatly between different algorithms, see
http://maximumcompression.com/ for a glance what is possible.
From your link, compression rates don't vary greatly. By and large you're looking at 80% compression for much of the top end of that table. Speed is also an issue, and the reason devs will use a particular compression scheme is balance between compression ratio and performance. If they're only getting 50% compression, it's due to performance reasons.
When you can reorganize the data you probably can save even more. In the
FP16 thread sebbi said that world data is usually 32-bit integers. One idea would be to reorganize world into
octree structure and store coordinates relative to the node they are in. If octree subdivision is chosen properly could save 1 byte of precision per value, maybe a few bits more. Might save maybe (I'm guessing here) 15% on the raw world data.
Not sure what you mean by world data. If it's stuff you're writing, like a Skyrim world state, you need to just write data to a database and can't afford to compress it. Compression is only really good for static data to be loaded. But let's give it your 15% gain and have a look at a hypothetical game.
50GB game. Save 2 GBs compressing 4 GBs of h.264 to h.265. Save 2 GBs by zipping up the world data. Audio is already compressed. Textures are already compressed. Meshes are already compressed. You're still above 40 GBs*. The only way to get smaller is to have less - there's no special compression scheme to double efficiency. Changing to Octree data structures and megatextures and adding all that extra effort doesn't save a great deal. If Switch is to get something like TR:RotTR, it'll need something like 20 GBs same as XB1, as least 15 GBs, unless aspects are reduced/removed to get it smaller (at additional cost to the developer).
We actually had this discussion years ago about download titles, I think started when MS forced a 40MB download limit on 360 games. The only area you can really save lots of storage is dynamic asset generation, such as creating texture on the fly in shaders. Everything else requires storage, which is why we've progressed from MB HDDs to GBs to TBs, and why 16 GB PCs aren't utterly extravagant when working with large, data-rich files., and why MS quickly revised their file limit policy!
* These are obviously make-believe numbers based on broad gut-feeling approximations. A break down of a PC game data files would be useful reference. Feel free to come up with your own speculations based on your own best case scenarios to see if you can get a radically smaller file. If there are games using uncompressed audio and large FMVs, obviously savings can be had!