Let's develop an open-source media archive standard

[der Mouse]

> I like the idea of Base64, because it's something that can still be
> readily decoded manually by a human (converting between number bases
> is easy once you understand the concept).

I'd hardly say "readily".  Hex I can read by eye; base64 I would use a
program for, even if it's a five-minute one-off hack.  (I can write a
rudimentary base64 unpacker in fifteen minutes; I know because I once
did.  Fifteen minutes would be unlikely to be enough time for me to
decode more than a few tens of bytes, without computer assist.)

> I'm not knowledgeable as to how the uuencode format is encoded.

It's conceptually almost identical to base64: it's a base-64
representation, representing three octets of binary data as four
encoded characters.  The major differences are probably that uuencode
has a length field on each encoded line and uses a different set of 64
characters.

"man 5 uuencode" on your friendly neighbourhood NetBSD box should
explain it - I'll be happy to send the manpage (nroff input or
formatted output, as desired) to anyone who wants a copy.

If it's a choice between base64 and uuencode, I'd say go with base64 -
it's more resistant to mangling by non-ASCII systems.  If you're
willing to commit to ASCII, btoa might be better - it uses base 85,
expanding by 4:5 rather than the 3:4 expansion produced by base64 or
uuencode.

However, the only reason I can see to use base64 instead of hex is a
desire to expand by only 3:4 instead of 1:2, and in my opinion that
verges on penny-wise and pound-foolish given the fundamental goals of
this archive format.  As Sellam writes,

> Given the current trends of hard drives, image filesize is not an
> issue.  Human readability is the prime concern.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B