This library allows you to communicate small amounts of data between air-gapped devices using sound. It implements a simple FSK-based transmission protocol that can be easily integrated in various projects. The bandwidth rate is between 8-16 bytes/sec depending on the protocol parameters. Error correction codes (ECC) are used to improve demodulation robustness.
This library is used only to generate and analyze the RAW waveforms that are played and captured from your audio devices (speakers, microphones, etc.). You are free to use any audio backend (e.g. PulseAudio, ALSA, etc.) as long as you provide callbacks for queuing and dequeuing audio samples.
It's designed for devices that are relatively close to one another that need to exchange information, like a PC and a phone or a con badge and a door lock. It even links to some mobile apps that can be used for proof-of-concept testing (but they're kind of old so they might not be installable for you).
The A.R.M. (Automatic Ripping Machine) detects the insertion of an optical disc, identifies the type of media, and autonomously performs the appropriate action:
- DVD / Blu-ray -> Rip with MakeMKV and Transcode with Handbrake
- Audio CD -> Rip and Encode to MP3 or FLAC and Tag the files if possible.
- Data Disc -> Make an ISO backup
It runs on Linux, it’s completely headless and fully automatic requiring no interaction or manual input to complete its tasks (other than inserting the disk). Once it completes a rip it ejects the disc for you and you can pop in another one.
HTTP encodings, headers, media types, methods, relations and status codes, all summarized and linking to their specification.
Once we start editing DNA on a large scale, we will need to keep track of what we do, revision histories, comment the new genes and add copyright notices. This is a suggested standard of entering ASCII information into the genome:
We will use 4-base codons to encode 7-bit ASCII. I know it is a bit primitive, but I think it does well enough and we might want to use the extra bit (see below). Each base codes two bits, and the complementary base codes the inverse:
A: 00 G: 01 C: 10 T: 11
Thus each character will be coded as four bases, read in the canonical 5'->3' direction.
The letters 'DNA' will thus become
01000100 01001110 01000001
G A G A G A T C G A A Gor GAGAGATCGAAG.
The problem when reading a DNA string is: which strand should we read? If we read the complementary strand, we will get an inverted string backwards. But since we use 7-bit ascii, we can test to see if every 8th bit is a one or zero, and deduce which side we are on. The reading process thus tries out the eight starting frames, and chooses the one which gives an unbroken stretch of ones or zeros. If the stretch are zeros, the bases are read and converted, if they are ones they are read to the end of the message, inverted and reversed. Note that some errors can become detectable this way, as interruptions of the stretches of similar bits.
To delineate the comments, we need markers. A standard could be the sequence corresponding to "COMMENT COMMENT COMMENT..." repeated a number of times (we don't want to use a long stretch of similar bases, since it would influence the bending of DNA, which might lead to unwanted effects).
A problem is that we might accidentally create active regions in the DNA with these comments; ideally we should choose a coding that minimizes the biological effects of the comment. Methylating the cytosine bases will also inactivate the comment. If it can be marked as an intron it could also be placed inside exons, making sure the comment will follow the gene it belongs to.
Thanks to John D. Gleason for the methylating and intron ideas.
A website that takes input in one form and converts it into others for your use and edification.
Possibly the best collection of audiovisual CODECs for Win32 and Win64 out there. Widely reputed to have no malware or spyware hidden anywhere within.