Use gzip or zlib for mmpz

[sqrvrt]

With the split away from Qt being something desirable, it would make sense to also change the from currently used Qcompress.

All formats are actually identical identical in terms of binary contents aside from header and footer:

• Zlib doesn't include any additional headers or footers by default, a decision primarily driven by network transfer, and which worse for desktop usage. They can be manually enabled.
• GZip files are recognized by Zlib and have a benefit of being able to be decompressed with any compatible tool regardless of the file name (magic bytes are embedded inside the file). IIRC zlib can also open and save gzip.
• Qcompress seems to have a custom header and footer that gzip does not recognize, so for end user the only hope is to run the xml through LMMS itself.

hex diff of project.mmpz vs project.mmp.gz

*** mmpz.hex	2025-11-15 12:12:58.998131341 +0300
--- mmp.gz.hex	2025-11-15 12:12:50.711448690 +0300
***************
*** 1,8 ****
   00
   03
!  ad
!  77
!  78
!  9c
   ed
   bd
--- 1,20 ----
+  1f
+  8b
+  08
+  08
+  fd
+  43
+  18
+  69
   00
   03
!  75
!  33
!  39
!  2e
!  6d
!  6d
!  70
!  00
   ed
   bd
***************
*** 22428,22435 ****
   ee
   2f
   ff
!  3f
!  b4
!  44
!  6a
!  53
--- 22440,22453 ----
   ee
   2f
+  7f
+  f9
   ff
!  01
!  31
!  c8
!  55
!  7c
!  78
!  ad
!  03
!  00

As such, I believe using zlib or gzip in retrospect would be beneficial. However, now backwards compat is also something to consider.

• I don't know if .mmp.gz would behave correctly in graphical environments in Windows or Mac, but if double extensions are possible, that would probably be the best way to go.
• Otherwise it would probably be smarter to change the file extension on newer version to something like .mmpgz or .mmpz2 rather than keep the file extension the same.
• If for some reason .mmpz is still the wanted extension, an additional check needs to be added that checks for previous header, and discards it and the footer if it exists. This would mean the change is invisible to the user and forces the check to be included until the end of time, whereas any previous option could at some point be split off into a helper util or even a 3rd-party like KArchive.

It may also be of interest to consider other options in the first case. Bzip2 offers better compression, but is heavier on compress/decompress, etc. The double extension would allow the file to be modular and subject to change at any later point, or even be a user preference.

[rdrpenguin04]

I was able to uncompress .mmpz files with zlib-flate after I stripped off the first several bytes. I'd say that would be the most painless conversion, but other options would be available.

In either case, all of the formats mentioned are detectable by their header. Zlib doesn't have a strict header persay, but there is a checksum byte to verify the header is intact, which would work plenty well. Gzip and Bzip2 both have very simple headers to detect. All in all, we could keep the file extension for familiarity and use some fairly simple code to detect the specific compression format in use.

[sqrvrt]

The reason I care about header magic is this:

$ file u39.mmpz
u39.mmpz: data
$ file u39.mmp.gz
u39.mmp.gz: gzip compressed data, was "u39.mmp", last modified: Sat Nov 15 09:12:29 2025, from Unix, original size modulo 2^32 241016

If file extension is ever lost, or the file gets onto a system without LMMS, or anything bad happens at all, the user will have a clear way to decompress the XML (the first lines of which are: <!DOCTYPE lmms-project>, <lmms-project type="song" creator="LMMS" creatorversion="1.3.0-alpha.1.974+pr8096.944328f" version="31"> and in case the file was corrupted, edit it. It would also get rid of mandatory lmms dump which as of now is the only "accessible" way to dump the file.

[rdrpenguin04]

That's definitely fair. I'd be interested to know if .mmp.gz can be forcibly recognized as an LMMS file, in that case.

[sqrvrt]

So after reading a bunch about MIME & file extensions, I think double extension would be too janky, I couldn't even get a right query to see something related to it.

Though multi-version .mmpz would still be entirely possible, tools like file recognize compression method by file magic, not by extension:

$ mv u39.mmp.gz u.mmpz
$ file u.mmpz
u.mmpz: gzip compressed data, was "u39.mmp", last modified: Sat Nov 15 09:12:29 2025, from Unix, original size modulo 2^32 241016

So it might be better to transfer the behavior to .mmpz or alike, and then just match based on embedded compression method. Though baseline gzip tool requires the extension to be provided explicitly with -S mmpz or piped as a stream. That is only the case with gzip though (and is probably an archaism), bzip2, xz and others work fine.