Example of PaperBack's output: <a href="https://a248.e.akamai.net/f/574/7105/8d/www.extremetech.com/wp-content/uploads/2012/08/extremetech-page-paperback-gif.gif" rel="nofollow">https://a248.e.akamai.net/f/574/7105/8d/www.extremetech.com/...</a>
With HCCB (High Capacity Color Barcode) of which an implementation is Microsoft Tag you can get 1.5 MB with 600dpi color on a A4. If you add the best compression techniques (cmix v7) depending on the source material you could get 8 times as much english text, easily fitting the pearls or religion: Tenach, New Testament, Quran, Mahabarata, The Dhamapada, the Atthakavagga and the Parayanavagga, Rhinoceros and Lotus Sutra, The Book of the Dead and the Sri Guru Granth Sahib and explanatory texts and commentary on one single A4.<p>Or you could get 4 minutes of stereo music, Opus@40Kbps or half an hour of speech Opus@6Kbps - (Vinyl LP seems to be more efficient and simpler for that).<p>Or the best 25 classical pieces in MIDI, for example Beethoven Symphony #5 in C minor is a 322 KB midi file (compressed 60 KB). With compressed ABC or Alda notation you could even fit 10 times as much. Or you can just read the ABC and automatically 'hear' the music in your head (is there a similar notation for human movement or dance i wonder...).<p>Even so perhaps a better and more cost effective system is microfilm, here an example of the bible printed on a 2 inch film: <a href="http://www.amazon.com/Microform-Bible-Much-Like-First/dp/B00FXHBBOO" rel="nofollow">http://www.amazon.com/Microform-Bible-Much-Like-First/dp/B00...</a> - you don't need a computer, just a lensing system.
It has one downside, the blind cannot use this unless you'd make an OCR to TTS or braille display converter on top of it.<p>Or as described in the book Mindhacker you could use Dutton Speedwords/Briefscript word abbreviations preferrable tailored to Esperanto to double the text on the microfilm or on your handwritten A4.
<a href="https://github.com/leonardoce/bumot" rel="nofollow">https://github.com/leonardoce/bumot</a>
This brings back memories.<p>In the late eighties, I wrote a program similar to this one for archiving one Apple II floppy disk on a sheet of paper.<p>One floppy disk is 140 kilobytes (35 tracks of 16 sectors containing 256 bytes each), so a sheet of paper with a 7-inch by 10-inch printed area needs a data density of just 2 kilobytes per square inch to fit a floppy disk, which comes out to a linear resolution of 128 dots per inch. This was (barely) within the specs of my dot matrix printer.<p>I was a teenager at the time so I had no clue about error correcting codes and the like, it was a straight bit-to-pixel mapping.<p>At the time, this was a write-only medium, as I did not have access to a scanner. No matter, I used it to archive my most important data disks, figuring that after a few years, technology would have improved enough to allow easy scanning. I eventually lost the sheets of paper, but the floppy disks themselves were robust enough to last until 1994, at which time I wrote a program to send them to my PC through a null-modem connection.
Reminds me of this <a href="https://en.wikipedia.org/wiki/Cauzin_Softstrip" rel="nofollow">https://en.wikipedia.org/wiki/Cauzin_Softstrip</a>.<p>Magazines would print out their source code and you could scan it in. Of course I had no money to buy such an expensive machine so was relegated to mind numbing typing and the inevitable typos that came with it.
So I'd like this on medium that's a bit more permanent than paper, but with similar information density per kg, and similar re-creatability without having any of the original tools available. I'd like to store data for say 100 thousand years.
>a) The key used for (en|de)cryption in version 1.00 provides at most an effective key strength of less than 50 bits (and likely far less, perhaps on the order of 15-25 bits, depending on password quality) instead of the expected 256 bits. Version 1.10 derives the encryption key from the password via key stretching, significantly improving key strength. This change causes a small delay in the encryption step.<p>>b) PaperBack version 1.0 implements ECB mode symmetric encryption. This mode is subject to a watermark attack and leaks information about the encrypted data. Version 1.00 changes the encryption mode to CBC, which mitigates this attack.<p>These are classic newb mistakes, and great reasons to not trust any encryption on any product unless it has been vetted by others.
This reminds me of <a href="http://ronja.twibright.com/optar/" rel="nofollow">http://ronja.twibright.com/optar/</a>
I converted the code to compile with Visual Studio and ran it. PaperBack was able to input a text file, create a "BMP", and read it back in. The destination file was the same as the source.<p>However the BMP files that PaperBack generates are not recognized and cannot be read by other programs. PaperBack can't read BMP files created by other applications.<p>I didn't try scanning the printed page directly with PaperBack. I used a separate computer to scan the page and create a BMP.
TRivia: If the printer can also output white ink, and the the encoding algorithm knows any dirt on the paper, then the capacity of the paper is the same even if the paper is dirty. <a href="http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=1056659&url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F18%2F22732%2F01056659" rel="nofollow">http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=105665...</a>
This inspired me prototype out a system which would use QR codes and use a smartphone camera for recovery, rather than a flatbed scanner.<p>Here's a demo PNG file which contains 48 QR codes (6x8) at V23 level with L correction (~7% recovery). That's 1091 bytes per code, or just over 51KB per page when printed at 300 dpi. This level of density seems to be very reliable using ambient lighting and an iPhone 5c.<p>I was also able to read a QR code which was 66% of that size, but it required turning on the iPhone's flash in order to be reliably read. That level of density would allow fitting 9x12 codes on a single page at 300 dpi, which would yield 115KB of data per page.<p>(At first I tried using 600 dpi, but at 1 dot per pixel the codes were totally unreadable by a cell phone. The above 115KB/page density is the equivalent of 4 dots per pixel at 600 dpi. The good news is this means the system doesn't require a 600 dpi printer. In fact, at 1 dot per pixel, the 51KB/page density is equivalent to 100dpi, and the 115KB/page density is equivalent to 150dpi).
In a slightly similar vein, there was a device that stored data on VHS cassettes as black and white blobs - <a href="https://web.archive.org/web/19970110151745/http://www.danmere.com/backer.html#info" rel="nofollow">https://web.archive.org/web/19970110151745/http://www.danmer...</a>
This reminds me of the Danmere Backer: <a href="http://linbacker.sourceforge.net/screenshots.html" rel="nofollow">http://linbacker.sourceforge.net/screenshots.html</a>
It would be nice to see a detailed comparison regarding alphanumeric efficiency, licenses and mobile readers, error correction, no error correction between the options below as Voiceye claims uncompressed 3M per A4, which is twice the efficiency of Paperback or QR codes. The mobile app is usable and supports midi encoding as well, but to make Voiceye codes you have to buy 500$ software. Are they using a form of compression?<p>* QR version 40 (177x177) tiled<p>* Voiceye<p>* Paperback without compression<p>* Grade 1 braille<p>* Grade 2 braille<p>* Morse code<p>* Optar<p>Braille would be suitable for people who are deaf and blind as well.
Has anyone actually used this? I'm intrigued by the idea and wonder if this is a viable backup option; and if so, are there more modern, maintained, and cross-platform open source solutions that do this?
there's also <a href="http://www.jabberwocky.com/software/paperkey/" rel="nofollow">http://www.jabberwocky.com/software/paperkey/</a>, for backing up private gpg keys on paper (text only).
this has some pretty powerful applications for example for politics or mass dissemination of paper based digital files for the public to quickly consume.<p>Imagine, if students could start posting free textbook pdf files just by handing out a piece of paper which you could scan, or maybe with a phone one day, and instantly receive the file.<p>Why not QR code? QR code needs connectivity while this solution would just require you to get your hands on the paper.