I had discovered or invented and implemented in 2008-2009 advanced data compression algorithms that attain on average 75%+ compression ratios, and even 85%+ and 94%+ compression ratios, emails sent in 2008 and then 2009.
I have a Podcast on this on YouTube. Here it is:
New Breakthrough Data Compression Algorithms in 2008-2009
On each of the podcasts, I wrote comments. I asked Gemini AI to write a blog article out of them, to just re-arrange my sentences and statements in those comments:
"The following are my comments on my YouTube podcasts on my advanced and breakthrough compression algorithms. Edit them for a post on Blogger or YouTube. Correct spellings and grammars, then collate the sentences and paragraphs into cohesive and coherent statements and paragraphs, into one cohesive whole, like a good book or well-written novel. Also arrange them chronologically and delete unnecessary repetitions of sentences and thoughts. Use my same sentences and statements. Do not try to add new sentences, Gemini. Same sentences from me but you can omit unnecessary sentences. Correct spellings too and grammar. Same contents in my DRAFT/draft, like 98% do not add sentences of your own."
Gemini's Response:
Here is your text, edited to correct spelling and grammar while removing repetitive thoughts, organized into a chronological narrative using only your original sentences and statements.
Text for Blogger blog post:
I had discovered or invented and implemented in 2008–2009 advanced data compression algorithms that attain on average 75%+ compression ratios, and even 85%+ and 94%+ compression ratios, as shown in emails sent in 2008 and then 2009. Maybe I already had a breakthrough data compression algorithm in 1999 to 2003 (Quezon City), or 2005 (here at SJDM, Bulacan), and 2006 or 2007, and then 2008 to 2009 (at Antipolo City). Years 2008 to 2009 were 17–18 years ago, when I was 33 to 34 years old. Made possible by a new internet connection at home and a new computer in late 2007 (October/December), you could email anytime, even every hour. Meaning, so many people and groups were emailed, providing more evidence of the truth of the existence of the advanced breakthrough compression algorithms. My breakthrough data compression algorithms in 2000–2003 and 2005–2006 I am not sure are saved or intact up to now. I had deleted them in my HDDs, unless they were recovered illegally via UNDELETE/RECOVER programs by authorities who somehow perhaps entered my home without a search warrant. Only the compression programs emailed in 2008 to 2009 we can say are real and evidence of the advanced data compression algorithms' existence—because they were sent to many individuals and groups mostly with C source codes and a few C++ source codes. Or unless there were copies of them in public internet cafes' HDDs that time when I was still paying for internet rental services in public internet shops or internet cafes. I emailed NASA, two or more NASA email boxes, maintainers of NASA mailboxes, the tech companies Microsoft, Google, Facebook, IBM, Intel, etc., the House of Representatives of the Philippines, the Senate of the Philippines, eBay, the PeaZip development team, the AVG Antivirus team, and the computer data storage companies. In 2009, the purpose of my emails again was to message a few corrections and solutions and improvements, how to decrypt my encrypted files, and also to state my concerns about the consequences and implications of those discoveries. There was really a compressed ZIP file named "ebay.zip" attached in my emails to eBay company. Maybe I also uploaded it on the Internet Archive (archive.org). I used a different username perhaps and the password I somehow forgot. One upload on the Internet Archive I couldn't delete anymore. I wonder now if the files were encrypted. I think YES, standard Zip file encryption only, or possibly also with my own encryption. I have sent encrypted ZIP files in my emails in 2008–2012, but me no encryption expert. If I have mentioned Tensor Processing Units (TPUs) of Google and some cryptanalysts still didn't know about TPUs when I was "emailing and emailing", then they must have been surprised about TPUs. I tried my best in making my own encryption secure, and was aware of quantum chips and quantum processors speed. Perhaps I was considering Shor's algorithm and Grover's algorithm speeds that even if they are used in cracking my encrypted files, it would still be hard decryption. But of course, government scientists, cryptographers, and cryptanalysts have their own very fast microprocessors, powerful workstations, or they have access to government or private supercomputers, quantum chips, and quantum processors by that time in the 2000s, or even cloud networks or "The Cloud" which I also mentioned in my emails. In the end, my breakthrough data compression algorithms and programs were highly optimized already and the EXE files were very small in size. They were "recursive compression algorithms", "hash data compression algorithms", and then "integer compression algorithms"—solved and fully implemented. I think it was in 2007 that I solved and fully implemented the RDC2 compression algorithm, with improvements and upgrades. The data structure I used for the "Big Integers (BigInts)" or Arbitrary-Precision Integers in implementing the RDC2 algorithm is a "singly-linked list". I created a good enough simple library for BigInts. I used the Turbo C compiler in solving and implementing the RDC2 algorithm, so I must have used first the "long" 32-bit integers and "long long" integers and "double" for the 64-bit integers, along with implementations using the "BigInts" integer library. RDC2 solution is largely based on "sorting frequencies" or any transforms on the "frequency table"; its compression performance is due to "context" and "finite state entropy" (FSE). I intended to fully implement and improve on my RDC2 programs in just one week but it became more than seven days. Then you add some "hash compression solutions" to a few RDC2 compression programs in the "RDC2 solutions ZIP file". And then, I revealed it later as "hash data compression" algorithm (solved) with many separate compression programs, improvements and updates, in another ZIP file. I also had an "lzhash.exe" sent to them or maybe it was "lzhash2.exe", and an emailed "zhash.exe" program—both implementations of "hash data compression" where the outputs are only just integers or hashes of hash functions. I remember my "lzhash.c" before, in 2008–2009, was a data compression program perhaps with "lzhashd.c" as decompressor. I created the "lzhash.c, lzhash.h" include library files to hide the fact that there was a previous "lzhash.c" compressor with decompressor in another email, or perhaps it was a single-file "lzhash.c" compressor/decompressor (codec). And then I tried understanding and implementing fractal compression in which I succeeded again. Did I have a "fractal compression" program in 2008–2009? Yes, I think so. Most possibly, iirc, gave them one fractal data compression program. Three fractal compression programs eventually, in 2008 or 2009, one correction to the one sent first and another one improved and higher compression version. Year 2010 na siguro the correction to the first fractal compression program sent to NASA and with a new improved fractal compression program version. I think I also created a fractal version of my "hash data compression" programs, the ones whose outputs are only hash integers or integer hashes for the input blocks; so it's a "fractal hash" compression program. They're almost the same in compression ratios performance, iirc. I created and developed a data compression program named "zstd.exe". I sent a "zstd.exe" to Facebook, which I possibly also sent to NSA or CIA (as a second party) without telling Facebook, but they knew it was "for Facebook". Most possibly I sent a "corrected bzip2 version" to the Bzip team and a bzip3 version with advanced compression performance similar to Zstd and then a bzip3 version with a "hidden" compress function in the "command-line options" in its EXE file. Very simply, I did not add that option in the command-line, but it's also possible that it is there in the command-line options with its unusual, suspicious, or lack of usage statements or displays on the computer screen for the curiosity of the programmers and testers. My other data compression programs were also encrypted, not just Nanozip. Nanozip (nz.exe) in 2008–2009 or maybe to 2010, I recalled the nanozip command-line program or saw it on the Internet. The nanozip program cannot be easily decrypted or deciphered in a Hex editor. It was encrypted, but yes perhaps easy to expert programmers who usually or routinely decompile binary EXE files. If that was my Nanozip (nz.exe), it is slow due to encryption at the start and decryption after compressing the input file, and then encrypting and decrypting in between the compression process. Then I have to delete the encryption and decryption pair, so that my nz.exe would be very fast. One compress function in my Nanozip program is "same as Zstd compression", meaning, the output compressed file is exactly the same. In 2008 to 2009, my Win32 GUI app which features Algorithm FGK I think still used "gtbitio.c", though I had a better and way faster BITIO library named differently, also included in few Win32 GUI apps or archives sent to just a very few tech companies or NASA/NSA. The Algorithm FGK source codes were possibly hidden via steganography or encrypted within the Win32 GUI program. The "C/C++ source codes" appear in "black and white" bitmapped image of a text file which were perhaps in "strike-through" fonts, iirc, and even added with some "text degradation functions" in the image to test the visual acuity and recognition of humans and OCR systems and visual recognition systems. I had my own simple AI program possibly named "zpaq" that time (or also "zstd.exe"/"nanozip") which emits "data compression programs" that are faster, so they brought me the original "zpaq.cpp" to optimize. In the end, one of the outputs of my AI program I named "zpaq.exe" (compression program-only) and sent to Facebook as well as its new versions and upgrades. Also a "nanozip.exe" and then to "nz.exe". Later, I added that option to "optimize" some C/C++ code that you show it; or if the C/C++ code you supplied is usable and faster, it is simply "learned" by my AI program. Yes, I think later I made it learn C++, and even simple machine code or assembly code via "inline assembly functions in C/C++". Maybe I will now in 2026 develop a Win32 GUI app for my static and dynamic Huffman compression programs, my Algorithm FGK implementation, and then also for my LZ77 and LZW and PPP/lzpgt compression programs in one GUI Windows program.






