The CinGG-20230131-x86_64.AppImage name will remain the same, but just will now be the multibit version. The CinGG-20230131-x86_64-multibit.AppImage will no longer exist. I am not going to bother creating an 8-bit appimage as it just seems unnecessary. I will just leave CinGG-20230131-x86_64-older-distros-multibit.AppImage as the same name to avoid any confusion.
2- Maybe I didn't understand correctly. Do you intend to rename all the 2023/24 appimages, removing the word multibit, and deleting the 8-bit ones? Will only the "older-distros" be left untouched? And the "i386" versions are all 8-bit? I will change the dates from 20230131 to 20240630 in the manual; however, I need the following data: Fedora 29/32; Ubuntu 16.04 and Debian 9/11 are changed in the latest version of 2024? Question to developers on 8-bit / multibit: I can't find anywhere instructions on how to compile system ffmpeg with 10-bit x265. Is it not that, as std, in ffmpeg all bit-depths are compiled and it is only in CinGG that there is something that prevents this, reducing the compilation to 8-bit only (thus making the 3 patches necessary)? In fact, my system ffmpeg has support for all bit-depths; why doesn't CinGG's ffmpeg (without patches)? In short, if this impediment is found, there would be no more need for the 3 patches and also the compile time would not double (it almost seems like it builds to 8-bit and then overlays a new 10-bit build on top of it).