Talk:EBZip - Revision history

Anonymoususer852: /* The viability ebuzip as a possible drop-in replacement candidate */ new section

2025-09-05T15:55:58Z

‎The viability ebuzip as a possible drop-in replacement candidate: new section

Anonymoususer852: /* ebzip caveats */ Updated section with topics about maliciously/errneously named files which can cause issues. Changed topic to also include EBUZip. Updated signed date.

2025-09-05T15:02:49Z

‎ebzip caveats: Updated section with topics about maliciously/errneously named files which can cause issues. Changed topic to also include EBUZip. Updated signed date.

Anonymoususer852: /* LZMA benchmarks against other compression/utilities */ Typos and wording.

2025-09-02T18:46:28Z

‎LZMA benchmarks against other compression/utilities: Typos and wording.

Anonymoususer852: /* zlib versus libdeflate versus LZMA benchmark (single electronic book) */ Wording on multi-threaded usage.

2025-08-20T11:42:19Z

‎zlib versus libdeflate versus LZMA benchmark (single electronic book): Wording on multi-threaded usage.

Anonymoususer852: /* zlib versus libdeflate versus LZMA benchmark (single electronic book) */ Split mkdwarfs' long command line syntax for legibility sake.

2025-08-20T07:38:08Z

‎zlib versus libdeflate versus LZMA benchmark (single electronic book): Split mkdwarfs' long command line syntax for legibility sake.

Anonymoususer852: /* LZMA benchmarks against other compression/utilities */ Added topic.

2025-08-20T06:34:02Z

‎LZMA benchmarks against other compression/utilities: Added topic.

Anonymoususer852: /* Deleting */ Improved syntax to make it less disasterous "-i" implied. Also worksaround root/other owned files.

2025-08-18T10:37:53Z

‎Deleting: Improved syntax to make it less disasterous "-i" implied. Also worksaround root/other owned files.

Anonymoususer852: Added talk page for topics that doesn't belong to main page.

2025-08-18T10:10:50Z

Added talk page for topics that doesn't belong to main page.

New page

== <code>ebzip</code> caveats ==
Intended to be a place to note down issues, as well as tips and tricks with <code>eb-4.4.3</code>.

=== Hardcoded to look specifically for a file that begins with <code>"CATALOGS"</code> (case-insensitive), or <code>"CATALOGS.ebz"</code> ===
Custom dictionaries doesn't always follow standard convention to store their content(s), like having "<code>START.ebz</code>" in the top level. Even if they do, they may also compress "<code>CATALOGS</code>" as "<code>CATALOGS.ebz</code>." <code>eb-4.4.3</code> specifically looks for either "<code>CATALOGS</code>" or "<code>CATALOGS.ebz</code>", and either decompress or compress the files specified within, per user's request, e.g. <code>ebzip -u</code> will tell it to decompress and rename any of the listed files that are noted in either "<code>CATALOGS</code>" or "<code>CATALOGS.ebz</code>", and has "<code>.ebz</code>" extension, ignoring any other files in the same path, and doesn't decompress "<code>CATALOGS.ebz</code>" even if instructed. There are ways to workaround that:

==== Decompress "<code>CATALOGS.ebz</code>" ====
In my case,
* Simply rename the decompressed "<code>HONMON</code>" to something like "<code>HONMON.old</code>",
* Copy the "<code>CATALOGS.ebz</code>" there, but have it named as "<code>HONMON.ebz</code>",
* Run decompression via the usual <code>ebzip -u</code> from the top level where it doesn't contain "<code>HONMON.ebz</code>" but only "<code>CATALOGS.ebz</code>",
* Once decompressed, move decompressed "<code>HONMON</code>" (not "<code>HONMON.old</code>") back to where "<code>CATALOGS.ebz</code>" was, have it renamed as "<code>CATALOGS</code>",
* Rename "<code>HONMON.old</code>" back to "<code>HONMON</code>".
Optionally, delete "<code>CATALOGS.ebz</code>" considering that is now redundant.

==== Decompress other <code>.ebz</code> that were not listed ====
Same as above, but instead of copying, you can just move it, as,
* <code>ebzip -u</code> will only look for "<code>CATALOGS</code>" or "<code>CATALOGS.ebz</code>", and
* It saves having to manually delete the redundant file(s) afterwards.

=== Zero-length (un)compressed files not overwritten upon manual intervention ===
When a path that has zero-length files, but are listed in either "<code>CATALOGS</code>" or "<code>CATALOGS.ebz</code>", <code>ebzip -u</code> for instance may not overwrite it. This may also apply if <code>ebzip -uf</code> is used. To fix this, just delete the zero-length files, ensuring that they have a duplicate file that does not have <code>.ebz</code> extension, then re-run the command. When compressing, the opposite is true, to look for duplicate zero-length files with <code>.ebz</code> extension, delete them and run the utility to compress instead.

On modern [[Linux]] environments, these could be achieved via the following:

==== Enumerating ====
find . -size 0 -type f

==== Deleting ====
find . -size 0 -type f -delete
Care must be taken to avoid any potential losses when running this command.

[[User:Anonymoususer852|Anonymoususer852]] ([[User talk:Anonymoususer852|talk]]) 10:10, 18 August 2025 (UTC)

← Older revision		Revision as of 15:55, 5 September 2025
Line 190:		Line 190:
	<references />		<references />
	[[User:Anonymoususer852\|Anonymoususer852]] ([[User talk:Anonymoususer852\|talk]]) 18:46, 2 September 2025 (UTC)		[[User:Anonymoususer852\|Anonymoususer852]] ([[User talk:Anonymoususer852\|talk]]) 18:46, 2 September 2025 (UTC)
		+
		+	== The viability <code>ebuzip</code> as a possible drop-in replacement candidate ==
		+
		+	As covered in the main page, that [[EBZip#EBUZip\|EBUZip]] uses the more modern libdeflate, I decided to also test this theory with once again using the same [[EBZip#Sample_file\|JMDict]] as the subject for these experimentation. On my modern Linux machine, running <code>ebuzip -i</code> on the path that contains JMdict as the name of subdirectory,
		+	=== Using the sample JMDict tarball as is ===
		+	==> /home/nobody/EPWING-research/JMDict-temp/a/JMdict_eng_2021-02-26_UTC/JMdict/DATA/HONMON.ebz <==
		+	130332672 -> 42407287 bytes (32.5%, ebzip level 5 compression)
		+
		+	==> /home/nobody/EPWING-research/JMDict-temp/a/JMdict_eng_2021-02-26_UTC/JMdict/GAIJI/GAI16H.ebz <==
		+	4096 -> 529 bytes (12.9%, ebzip level 5 compression)
		+
		+	==> /home/nobody/EPWING-research/JMDict-temp/a/JMdict_eng_2021-02-26_UTC/CATALOGS <==
		+	2048 bytes (not compressed)
		+
		+	This is likely compressed using <code>ebzip</code> with zlib. Running <code>ebuzip -u</code> indicates the following,
		+	==> uncompress /home/nobody/EPWING-research/JMDict-temp/a/JMdict_eng_2021-02-26_UTC/JMdict/DATA/HONMON.ebz <==
		+	output to ./JMdict/DATA/HONMON
		+	51.5% done (67108864 / 130332672 bytes)
		+	completed (130332672 / 130332672 bytes)
		+	==> uncompress /home/nobody/EPWING-research/JMDict-temp/a/JMdict_eng_2021-02-26_UTC/JMdict/GAIJI/GAI16H.ebz <==
		+	output to ./JMdict/GAIJI/GAI16H
		+	completed (4096 / 4096 bytes)
		+	==> copy /home/nobody/EPWING-research/JMDict-temp/a/JMdict_eng_2021-02-26_UTC/CATALOGS <==
		+	output to ./CATALOGS
		+	the input and output files are the same, skipped.
		+
		+	Then I ran <code>ebuzip -q -z -l 5</code> which compresses it using the same level (5) compression, via libdeflate and silenced output. After a few minutes, I was greeted with my prompt, so I ran <code>ebuzip -i</code>,
		+	==> /home/nobody/EPWING-research/JMDict-temp/a/JMdict_eng_2021-02-26_UTC/JMdict/DATA/HONMON.ebz <==
		+	130332672 -> 40120400 bytes (30.8%, ebzip level 5 compression)
		+
		+	==> /home/nobody/EPWING-research/JMDict-temp/a/JMdict_eng_2021-02-26_UTC/JMdict/GAIJI/GAI16H.ebz <==
		+	4096 -> 513 bytes (12.5%, ebzip level 5 compression)
		+
		+	==> /home/nobody/EPWING-research/JMDict-temp/a/JMdict_eng_2021-02-26_UTC/CATALOGS <==
		+	2048 bytes (not compressed)
		+
		+	=== EBUZip with zlib decompressing the same sample compressed JMDict, then recompressing it using zlib at first, then recompressing it finally using libdeflate ===
		+	I then decided to experiment JMDict but with <code>ebuzip</code> compiled to use zlib, in a separate path, which I used that to first decompress the original zlib level 5 JMDict, then recompress it again using zlib level 5, before it is finally recompressed (after decompressing) using libdeflate. Running <code>ebuzip -i</code> shows,
		+	==> /home/nobody/EPWING-research/JMDict-temp/b/JMdict_eng_2021-02-26_UTC/JMdict/DATA/HONMON.ebz <==
		+	130332672 -> 41985166 bytes (32.2%, ebzip level 5 compression)
		+
		+	==> /home/nobody/EPWING-research/JMDict-temp/b/JMdict_eng_2021-02-26_UTC/JMdict/GAIJI/GAI16H.ebz <==
		+	4096 -> 529 bytes (12.9%, ebzip level 5 compression)
		+
		+	==> /home/nobody/EPWING-research/JMDict-temp/b/JMdict_eng_2021-02-26_UTC/CATALOGS <==
		+	2048 bytes (not compressed)
		+
		+	As you can see, <code>HONMON.ebz</code> has different overall size/compression ratio compared to the sample compressed JMDict. zlib project is still being maintained, so it's not terribly surprising to see ever so slight increase in compression ratio of 0.3%.
		+
		+	Again, decompressing it using the same <code>ebuzip -u</code>,
		+	==> uncompress /home/nobody/EPWING-research/JMDict-temp/b/JMdict_eng_2021-02-26_UTC/JMdict/DATA/HONMON.ebz <==
		+	output to ./JMdict/DATA/HONMON
		+	51.5% done (67108864 / 130332672 bytes)
		+	completed (130332672 / 130332672 bytes)
		+	==> uncompress /home/nobody/EPWING-research/JMDict-temp/b/JMdict_eng_2021-02-26_UTC/JMdict/GAIJI/GAI16H.ebz <==
		+	output to ./JMdict/GAIJI/GAI16H
		+	completed (4096 / 4096 bytes)
		+	==> copy /home/nobody/EPWING-research/JMDict-temp/b/JMdict_eng_2021-02-26_UTC/CATALOGS <==
		+	output to ./CATALOGS
		+	the input and output files are the same, skipped.
		+
		+	Finally, with both <code>ebuzip -q -z -l 5</code> and <code>ebuzip -i</code>,
		+	==> /home/nobody/EPWING-research/JMDict-temp/b/JMdict_eng_2021-02-26_UTC/JMdict/DATA/HONMON.ebz <==
		+	130332672 -> 40120400 bytes (30.8%, ebzip level 5 compression)
		+
		+	==> /home/nobody/EPWING-research/JMDict-temp/b/JMdict_eng_2021-02-26_UTC/JMdict/GAIJI/GAI16H.ebz <==
		+	4096 -> 513 bytes (12.5%, ebzip level 5 compression)
		+
		+	==> /home/nobody/EPWING-research/JMDict-temp/b/JMdict_eng_2021-02-26_UTC/CATALOGS <==
		+	2048 bytes (not compressed)
		+
		+	=== Observation notes ===
		+	<code>ebuzip</code> does not indicate whether or not,
		+	* If compression was done by <code>ebzip</code>, and,
		+	* The library used, if it was zlib compressed or that it was subsequently using libdeflate.
		+	Therefore, no matter which one of the two different <code>ebuzip</code> was used overall, the results are the same, with compressed sizes being different.
		+
		+	As my aim with either <code>ebzip</code> or <code>ebuzip</code> is to simply decompress the files, before recompressing them all using LZMA via the likes of [[DWARFS]] or [[SquashFS]], I have not tested whether or not if JMDict with EBUZip via libdeflate compression could successfully load using a general e-book viewer. But considering that the decompressing and recompressing indicates that the file could still be read, even if I used <code>ebuzip</code> here instead of the original <code>ebzip</code>, I am going to assume it will successfully load.
		+
		+	[[User:Anonymoususer852\|Anonymoususer852]] ([[User talk:Anonymoususer852\|talk]]) 15:55, 5 September 2025 (UTC)

@@ Line 63: / Line 63: @@
 | 328,192,000
 |-
-| <code>ebzip -z -l 5</code><br />(zlib)
+| <code>ebuzip -z -l 5</code><br />(zlib)
 | 42,035,200
 | 1,393,920,000
@@ Line 77: / Line 77: @@
 | 33.43%
 |-
-| <code>ebzip -z -l 5</code><br />(libdeflate)
+| <code>ebuzip -z -l 5</code><br />(libdeflate)
 | 40,171,520
 | 1,383,505,920
@@ Line 150: / Line 150: @@
 XZ compression results are provided for the sake of discussion only, more on this in conclusion. While it does show extremely good results against all other utilities, the seek times are abysmally poor, worse than DWARFS with LZMA2 on machines with weaker hardware. Tests confirms liblzma having better compression regardless, against both zlib and libdeflate.
-NHKAccent is the exception here, with compression results indicating poor results. This is due to electronic book containing multimedia files, which won't compress well if it was already compressed.
+NHKAccent is the exception here, with poor compression results. This is due to electronic book containing multimedia files, which won't compress well if it was already compressed.
 It is worthy to note here that compression/archiving utilities embracing liblzma, could by default take advantage of multi-threading, at the expense of producing potentially larger file. This however, is a small trade off, for effectively making full use of available CPU in the given environment.
@@ Line 183: / Line 183: @@
 <references />
-[[User:Anonymoususer852|Anonymoususer852]] ([[User talk:Anonymoususer852|talk]]) 06:34, 20 August 2025 (UTC)
+[[User:Anonymoususer852|Anonymoususer852]] ([[User talk:Anonymoususer852|talk]]) 18:46, 2 September 2025 (UTC)

@@ Line 152: / Line 152: @@
 NHKAccent is the exception here, with compression results indicating poor results. This is due to electronic book containing multimedia files, which won't compress well if it was already compressed.
-It is worthy to note here that compression/archiving utilities embracing liblzma, could be configured to take advantage of multi-threading by default, at the expense of producing potentially larger file. This however, is a small trade off, for effectively making full use of available CPU in the given environment.
+It is worthy to note here that compression/archiving utilities embracing liblzma, could by default take advantage of multi-threading, at the expense of producing potentially larger file. This however, is a small trade off, for effectively making full use of available CPU in the given environment.
 === Modern compressed file system with multiple electronic books shootout ===

@@ Line 40: / Line 40: @@
 [[DWARFS]] example parameters:
-   mkdwarfs --input . --output=../JMdict_eng_2021-02-26_UTC.dwarfs --block-size-bits=26 --compression=lzma:level=9:extreme --schema-compression=lzma:level=9:extreme --metadata-compression=lzma:level=9:extreme --no-history --pack-metadata=all,force --file-hash=sha3-512 --no-history-timestamp --no-create-timestamp --no-history-command-line
+   mkdwarfs --input . --output=../JMdict_eng_2021-02-26_UTC.dwarfs --block-size-bits=26 --compression=lzma:level=9:extreme --schema-compression=lzma:level=9:extreme --metadata-compression=lzma:level=9:extreme --no-history \
 [[SquashFS]] example parameters:

← Older revision		Revision as of 06:34, 20 August 2025
Line 32:		Line 32:

	[[User:Anonymoususer852\|Anonymoususer852]] ([[User talk:Anonymoususer852\|talk]]) 10:10, 18 August 2025 (UTC)		[[User:Anonymoususer852\|Anonymoususer852]] ([[User talk:Anonymoususer852\|talk]]) 10:10, 18 August 2025 (UTC)
		+
		+	== LZMA benchmarks against other compression/utilities ==
		+	In response to maintainer of <code>ebu</code>'s blog entry,<ref>[http://ikazuhiro.s206.xrea.com/article.php/20190701203038572 EPWINGを圧縮する (libdeflateで) / Compressing EPWING via libdeflate - Kazuhiro's blog]</ref> I decided to run a couple of benchmarks with different dictionaries, books or other referencing materials on my end. The following packages and their versions are as follows; kernel-6.15.8, zlib-1.3.1, libdeflate-1.24, xz-5.4.2, dwarfs-0.12.4, squashfs-tools-4.7.1.
		+
		+	=== zlib versus libdeflate versus LZMA benchmark (single electronic book) ===
		+	For the following, file sizes are reported from <code>ls -l</code>, therefore size would be reported in blocks<ref>[https://unix.stackexchange.com/questions/28780/file-block-size-difference-between-stat-and-ls file block size - difference between stat and ls - Unix & Linux - Stack Exchange]</ref>. The tested dictionaries using no compression, zlib, libdeflate, or [[XZ]] are [[tar\|tarballed]] for consistency. For compressed file systems, XZ's LZMA2 is used. Both zlib and libdeflate has a maximum compression level of 5, anything beyond 5 would result in error, however XZ goes up to level 9, and has further options like <code>--extreme</code> as well as various other tweaks which I will keep it simple and use <code>xz -9evv</code> instead.
		+
		+	[[DWARFS]] example parameters:
		+	mkdwarfs --input . --output=../JMdict_eng_2021-02-26_UTC.dwarfs --block-size-bits=26 --compression=lzma:level=9:extreme --schema-compression=lzma:level=9:extreme --metadata-compression=lzma:level=9:extreme --no-history --pack-metadata=all,force --file-hash=sha3-512 --no-history-timestamp --no-create-timestamp --no-history-command-line
		+
		+	[[SquashFS]] example parameters:
		+	mksquashfs . ../JMdict_eng_2021-02-26_UTC.squashfs -b 1048576 -comp xz -Xdict-size 100% -progress -info -no-xattrs
		+
		+	Percentages are rounded to two decimal points, otherwise rounded up. Compression ratio against uncompressed in percentage is offered instead.
		+
		+	{\| border="1" align="center" style="text-align:center;" cellpadding="6"
		+	\|
		+	\| [[EBZip#Sample_file\|kanjidic]]
		+	\| NHKAccent
		+	\| Eijiro
		+	\| Kenkyusha eiwa daijiten v6
		+	\| Kenkyusha waei daijiten v5
		+	\|-
		+	\| ''No compression''
		+	\| 130,385,920
		+	\| 1,578,055,680
		+	\| 1,374,771,200
		+	\| 484,945,920
		+	\| 328,192,000
		+	\|-
		+	\| <code>ebzip -z -l 5</code><br />(zlib)
		+	\| 42,035,200
		+	\| 1,393,920,000
		+	\| 379,975,680
		+	\| 117,596,160
		+	\| 109,721,600
		+	\|-
		+	\| ''Compression ratio against uncompressed in percentage''
		+	\| 32.24%
		+	\| 88.33%
		+	\| 27.63%
		+	\| 24.25%
		+	\| 33.43%
		+	\|-
		+	\| <code>ebzip -z -l 5</code><br />(libdeflate)
		+	\| 40,171,520
		+	\| 1,383,505,920
		+	\| 353,269,760
		+	\| 107,765,760
		+	\| 102,113,280
		+	\|-
		+	\| ''Compression ratio against uncompressed in percentage''
		+	\| 30.81%
		+	\| 87.67%
		+	\| 25.70%
		+	\| 22.22%
		+	\| 31.11%
		+	\|-
		+	\| <code>xz -9evv -T1</code><br />(liblzma)
		+	\| 21,607,608
		+	\| 1,350,900,536
		+	\| 197,134,768
		+	\| 55,220,788
		+	\| 50,109,852
		+	\|-
		+	\| ''Compression ratio against uncompressed in percentage''
		+	\| 16.57%
		+	\| 85.61%
		+	\| 14.34%
		+	\| 11.39%
		+	\| 15.27%
		+	\|-
		+	\| <code>xz -9evv -T0</code><br />(liblzma)
		+	\| 21,607,616
		+	\| 1,351,560,168
		+	\| 202,934,760
		+	\| 56,670,664
		+	\| 50,747,640
		+	\|-
		+	\| ''Compression ratio against uncompressed in percentage''
		+	\| 16.57%
		+	\| 85.65%
		+	\| 14.76%
		+	\| 11.69%
		+	\| 15.46%
		+	\|-
		+	\| <code>mk[[DWARFS\|dwarfs]]</code><br />(liblzma)
		+	\| 22,145,746
		+	\| 1,353,699,364
		+	\| 212,307,176
		+	\| 60,043,728
		+	\| 54,541,980
		+	\|-
		+	\| ''Compression ratio against uncompressed in percentage''
		+	\| 16.99%
		+	\| 85.78%
		+	\| 15.44%
		+	\| 12.38%
		+	\| 16.62%
		+	\|-
		+	\| <code>mk[[SquashFS\|squashfs]]</code><br />(liblzma)
		+	\| 31,793,152
		+	\| 1,367,302,144
		+	\| 272,068,608
		+	\| 81,805,312
		+	\| 160,956,416
		+	\|-
		+	\| ''Compression ratio against uncompressed in percentage''
		+	\| 24.38%
		+	\| 86.64%
		+	\| 19.79%
		+	\| 16.87%
		+	\| 49.04%
		+	\|}
		+
		+	XZ compression results are provided for the sake of discussion only, more on this in conclusion. While it does show extremely good results against all other utilities, the seek times are abysmally poor, worse than DWARFS with LZMA2 on machines with weaker hardware. Tests confirms liblzma having better compression regardless, against both zlib and libdeflate.
		+
		+	NHKAccent is the exception here, with compression results indicating poor results. This is due to electronic book containing multimedia files, which won't compress well if it was already compressed.
		+
		+	It is worthy to note here that compression/archiving utilities embracing liblzma, could be configured to take advantage of multi-threading by default, at the expense of producing potentially larger file. This however, is a small trade off, for effectively making full use of available CPU in the given environment.
		+
		+	=== Modern compressed file system with multiple electronic books shootout ===
		+	Author of <code>ebu</code> mentioned the case with smartphones, which I do personally find that these are also limited in performance, not just with storage capacities. [[SquashFS]] was or is used in Android devices,<ref>[https://android.stackexchange.com/questions/258236/squashfs-explanation-for-android-system SquashFS explanation for Android system - Android Enthusiasts - Stack Exchange]</ref> so it makes sense to try using that on non system files in addition.
		+
		+	For these tests, the sample data consists of ~189 dictionaries in a single directory. Both [[DWARFS]] and [[SquashFS]] are configured to use XZ's LZMA2 where possible, as it is known to be one of the best, freely available (especially under Unix-like platforms) compression. Both DWARFS and SquashFS parameters are the same as in prior section. Due to the inherent way of how <code>ebuzip</code> works, requiring "<code>CATALOGS</code>" to be in the top directory, both variations of <code>ebuzip</code> using either zlib or libdeflate are omitted from this test. Besides, single compression job per dictionary, not including other files in the that path, e.g. "<code>START</code>" would make the overall process time consuming, if the process isn't already tedious that it requires extensive scripting.
		+
		+	{\| border="1" align="center" style="text-align:center;" cellpadding="6"
		+	\| Method
		+	\| Size (blocks)
		+	\|-
		+	\| Uncompressed<br />[[tar]]
		+	\| 29,014,026,240
		+	\|-
		+	\| [[DWARFS]]
		+	\| 10,613,886,184
		+	\|-
		+	\| [[SquashFS]]
		+	\| 12,269,518,848
		+	\|}
		+
		+	Where DWARFS shines, is the ability to also save on segmenting data, in addition to file de-duplication. For a small penalty I've given to DWARFS, in that it is to use sha3-512 as hash, it still compresses the collection better and faster, than SquashFS. Then again, the focus here is on overall file size, not performance in file creation.
		+
		+	=== Conclusion ===
		+	Now of course, there are plenty of other compression utilities available, such as, but are not limited to [[Zstandard]], [[BZip3]], [[LZO]], etc. From the various results I have read, indicates that these other compression benchmarks, while trading better performance, these fall behind in final size constraints. The benchmark showcase here outlines the need to have as small of a compressed file as possible, with modern compression utilities and modern PC hardware, therefore making (speed-wise) performance testing out of the scope, as is the idea of creating the likes of [[ZIP]] bombs, or nested compressed files out of the scope.
		+
		+	I have also tried to run <code>mkfs.[[EROFS\|erofs]]</code> in order to include it against the modern compressed file system with multiple dictionaries shootout. With version 1.8.10, no matter what parameters I set with LZMA <code>level=9</code> or <code>level=109</code> (109 is the extreme variant), even with lowering <code>dictsize=</code>, the results would cause system to run out of memory (16GB of RAM) before even completing the file system creation.
		+
		+	These benchmarks are in no way discrediting or disavowing the use of libdeflate over zlib. If file size is a concern, more modern compression algorithms and/or compression techniques could be considered. Modern EPWING viewer programs generally don't care if the electronic book is compressed using zlib or not compressed at all, and there are many ways of handling decompression transparently in modern Unix-like environments. Even more so, are the ever growing hardware performance as well as affordability with storage capacities in modern computing, questions the use of the what is widely considered as legacy compression algorithms for data archival. Last but not least, while single-threaded compression (as witnessed in the likes of <code>xz -9evv -T1</code> above) or tasks might be extremely beneficial in reducing overheads, especially with LZMA2, it is also a slow process which may subsequently not translate well in modern, demanding contexts, where time honored traditions are casted away for practical, convenient, modernized, and easy to use solutions.
		+
		+	<references />
		+	[[User:Anonymoususer852\|Anonymoususer852]] ([[User talk:Anonymoususer852\|talk]]) 06:34, 20 August 2025 (UTC)

@@ Line 1: / Line 1: @@
-== <code>ebzip</code> caveats ==
+== <code>ebzip</code>/<code>ebuzip</code> caveats ==
-Intended to be a place to note down issues, as well as tips and tricks with <code>eb-4.4.3</code>.
+Intended to be a place to note down issues, as well as tips and tricks with either <code>eb-4.4.3</code> and/or <code>ebu-4.5-20220808</code>.
 === Hardcoded to look specifically for a file that begins with <code>"CATALOGS"</code> (case-insensitive), or <code>"CATALOGS.ebz"</code> ===
@@ Line 18: / Line 18: @@
 * <code>ebzip -u</code> will only look for "<code>CATALOGS</code>" or "<code>CATALOGS.ebz</code>", and
 * It saves having to manually delete the redundant file(s) afterwards.
 === Zero-length (un)compressed files not overwritten upon manual intervention ===
@@ Line 31: / Line 37: @@
 Care must be taken to avoid any potential losses when running this command.
-[[User:Anonymoususer852|Anonymoususer852]] ([[User talk:Anonymoususer852|talk]]) 10:10, 18 August 2025 (UTC)
+[[User:Anonymoususer852|Anonymoususer852]] ([[User talk:Anonymoususer852|talk]]) 15:02, 5 September 2025 (UTC)
 == LZMA benchmarks against other compression/utilities ==

@@ Line 28: / Line 28: @@
 ==== Deleting ====
-   find . -size 0 -type f -delete
+   find . -size 0 -type f -exec sudo rm -iv "{}" \;
 Care must be taken to avoid any potential losses when running this command.
 [[User:Anonymoususer852|Anonymoususer852]] ([[User talk:Anonymoususer852|talk]]) 10:10, 18 August 2025 (UTC)