Suppose I wanted to make an epub???

[ProDigit]

Originally Posted by Elfwreck

Winrar is intended to be Windows-only. No idea why not 7z, except that it's a less universal system. Many programs can do zip; only 7zip can do 7z files. They went with the most common & accessible type of compression.

First, I think it's been said that the Jetbook Color has some form of mobile Winows installed on it.

Second, 7Z is only for windows. winrar is ported to all os'es including mac, and linux.

No, it's like an mp3 player that doesn't play wav files, no matter how popular they are, even if they make smaller files with the same sound quality.

Most readers can read uncompressed htmls, which in audio are like wav files.
epub is like zip, or mp3; while I would have chosen rar or 7z, which would translate to .wma or ogg as audio.
audiophiles would confirm wMA to be best for low bitrate, high compression, and ogg for high bitrate high compression.

[ATDrake]

7z is available in a command-line port that works on Unix-like OSes, including the Mac. Several front-ends are available, mostly just for unarchiving.

RAR is a proprietary commercial format and last I bothered to check, the developer wanted $30 per install of the official RAR-creation software (discount bundle pricing available) and had a bit in the license of the unrar program saying that its source was not to be reverse-engineered to create a RAR-encoder.

Zip is common, understood, at a reasonably stable point in its development, and readily available or portable to just about any OS, and there are plenty of tools from multiple sources to deal with it, which is a decided advantage over the other formats, even once one factors out the commercial proprietary aspects of stuff.

[Freeshadow]

Zip not only did, it's a nearly ISO standard.
Check RFC 1961
In fact if discussing compression methods it is better to refer to their own names instead of the names of file archive containers using said method, as we have seen, it might help avoid confusion.
So let's have a clean start from here on:
The metbod used in zip files (deflate) is used in several cases which can be roughly sorted in two groups:
The 1st uses not only the method, but the file structure too - in which case the file can be renamed to zip, altered and named back. This is correct for e.g. pkg files of some id shooter games and partly for epubs.
The 2nd uses the method to compress its data steams but doesn't necessarily follow zip file structure. PNGs are deflate compressed too.
7zip or: Here the mixing up began:
7z archives don't use the deflate method. They use lzma and are therefor out of discussion for epubs period.
The zips(!) produced by 7z use a more efficient DEFLATE implementation and are an option to consider.
This is why I pointed to: advancemame.sourceforge.net/comp-readme.html
It uses the same deflate implementation like 7zip. There you go: smaller yet epub spec-compliant zip files.
Doing a search on the topic I came across KZIP which is said to have an even higher deflate based compression than the above mentioned: advsys.net/ken/utils.htm

If it's still better than 7zips deflate, if it won't choke on the uncompressed mimetype file required by epub specifications I don't know but it sounds like worth trying.

As for your question why not to use solid archives like 7z: no long answer but some keywords: memory usage; decompression spee; dictionary size. Similar goes with your mp3 comparison: libvorbis or its smaller kin libtremor (being a lot less stable) need far more power than the small audio player offer. Haven't you never wondered why only the bigger ones do OGG?
Going back from your comparison with ebooks: How long did you say the file 'll need to open and how much RAM is needed for this!?

That's all dear Digit and I shall no longer distract you from reading the epub specifications which people present here and being far wiser on the subject than me suggested to you.

IMHO it's the best thing you can do, because randomly deleting stuff, while still hoping things don't get hopelessly f*d upis as far from an optimisation attempt, as amputation of private parts is from an weight loss therapy.

[Elfwreck]

Originally Posted by ProDigit

Most readers can read uncompressed htmls, which in audio are like wav files.

They can?

My Sony can't. Kindles can't. Nooks can't. I don't know about Kobo devices. My PocketEZ says it reads HTML, and they do open, but the formatting is messed up & it adds random hyphenations and breaks in the middles of words without hyphens.

Most dedicated ereaders can't display plain HTML in a way that's readable.

----
As was mentioned: Zip was chosen, for various reasons include widespread availability. Part of the reasoning was probably that the exact compression level isn't that important for over 90% of ebooks; they are *tiny* files. The ones that aren't tiny files, tend to be picture-heavy; compression levels don't matter much for those.

Current ebook tech doesn't have good support for *any* non-linear text, and the more complex the work, the less support there is. Ebook readers don't have great navigation options for hundreds of chapters--and the compression involved in .zip versus .7z is not a major part of that.

I do understand it's frustrating to see a standard that looks inefficient, but this one was established based on a lot of factors that no one publisher is going to care about.

[ProDigit]

Originally Posted by Freeshadow

Haven't you never wondered why only the bigger ones do OGG?

There are virtually no differences anymore between ogg and mp3 decoding. Encoding is so optimized, that ogg can optimize compression by 2,5x (that is 250%), for 80% of the encoding speed compared to mp3.
Tests on battery life on mobile devices have shown that decoding ogg only takes marginally more power than mp3 (you lose less than 18% playing back an ogg file and about equal when plying back an ogg with similar quality).

From hardware side there's no noticeable increase needed to decode ogg.

Concerning ebook, a solid archive would make less sense when the reader extracts each html separate, but even if you select a large ebook, say 70MB, compressed to 7MB (say it has a lot of pictures in it), decoding needs less than 5MB of ram.
Most ebooks are less than 1MB (most of my epub books are about 750kB in size), they need less than 750kB of ram for decoding for solid archives, and I'm reading in 7z, that zip needs at least 2MB even for a 750kb file (don't know if that's true though).

[Freeshadow]

From hardware side there's no noticeable increase needed to decode ogg.

noticeable is a comfortably foggy definition which I simply won't accept as an argument, because what for a smartphone or a similar device might be an minor numbercrunching task may lay beyond the hardware limits of a small dedicated player.
On archives: well I use compression tools as long as I've used a computer. Floppies weren't cheap back then.
I know by daily experience that solid compression need a fair bit more of power and time to decode.
It's meant for archiving purposes not for active use. Would epub use it, there were enough small devices. choking on books only because of their decompression requirements. Space-saving backfired. This are all aspects to be taken into consideration when developing a standard. Just think about it.

[ProDigit]

You'll need the processor of a needle pin size, to decode ogg, consuming mere micro watts of power, operating at a speed of a few megahertz. You think that's much?
OGG gets decoded at over 300x at speeds of only 1,66Ghz dual core cpu.
currently ANY device can decode ogg, if there was an adventurous soul out there willing to write a decoder for a gameboy, it would be able to do that.

I know by daily experience that solid compression need a fair bit more of power and time to decode.
It's meant for archiving purposes not for active use. Would epub use it, there were enough small devices. choking on books only because of their decompression requirements.

You mean 'encoding'?
Decoding requires virtually nothing, ~1MB of ram; but I understand solid archiving is not chosen because of the benefit that the opposite brings

[JSWolf]

The advantage of OGG is that at a similar size to a given MP3, the sound quality will be better. At a similar sound quality to a given MP3, the OGG file will be smaller. OGG requires almost no processor to decompress. So if you have a DAP that handles OGG, it's better to encode in OGG then MP3.