## Introduction: Predictive* Digital Music Synthesizer (Pandora's Box #2)

(*)Originally this was "preemptive", because I heard a rumor that someone else

had announced it. However "it" (theirs) was more of a data mining scheme in my opinion

than an automatic sound generator. This is "predictive" because it reads and sounds

THE NUMBER which is PROVEN to contain ALL possible SOUNDS in a usable way.

Someone claimed to have invented one in 1971, before PC's were powerful enough.

I responded by saying there were no PC's not even Altairs in 1971, but with 1971

technology I would have used the following 1971 technology with MY METHOD.

The Pandora's Box instructable now includes info about a Singing Calculator Number,

which is from the sequential digits of the number that is the subject of this instructable,

and a planned simple device for feeding that number into a speaker to get music.

NO PROGRAMMABLE CHIP IS NEEDED.

This sounds different than my other Pandora's Box which needs a programmable chip,

but when the schematic is done for this, so will be the uncomputerized original P Box.

## Step 1: More Info, What Is Needed?

I have reduced and minimalized this so that a small handful of

nice cheap 4040 and 4051 chips may be all you need.

(and battery, wire, solder, iron, speaker, breadboard, etc.)

HEADACHE WARNING: MATH AHEAD (Only "math heads" need to know.)

At this point the simplest musical calculator using "normal numbers" will use a brute force

method that pulls digits out of thin air using a binary counter, which is not considered a

computer, although it calculates all possible combinations starting with zero. Normal numbers

contain all other numbers, and the ones which can be made by counting contain them all

in order. And this is interesting because files and numbers are both the same thing, strings

of bits. This is well demonstrated in the simplest way I can imagine, in that number which

will play as the calculator song.

We say that Pi has an infinite number of digits, and that the digits are arranged "randomly"

in such a way that it contains an equal number of each number, so it is called Normal

(mathematically speaking). If I was making a Pi player, it would sound like the hiss of

static on a radio, because that is the sound of random. No one says that counting is

random, and a number made by ordinary counting will not skip a number, so we can

be sure that any number can be found in sorted order in it's place, leaving no doubt,

as someone could doubt that Pi has a certain number in it if they looked all over it

and never found what they were looking for.

The number "zero point one two three..." is the simplest demo of the musical number

concept, not necessarily the most practical one. Most understandable. I really feel

like I have to condescend and KISS about my most incredible inventions so people

because of responses like this:

Digg my "Holodeck"

The original Pandora's Box instructable had constraints, so that it's output would

never sound like static. This one does not have noise-avoiding constraints, except

that as another demo it is not designed to go so far into the calculation that we

will lose the sense of the pattern in the sound which is the process of counting.

It is very important to imagine that the number one need not be the first sound.

If this particular method of making sound were advanced far enough, then

the number one could actually represent the first song on the popularity chart!

I hope to get deeper into enumeration in future "musical number theory" instructables.

My more current enumeration research actually involves effective skipping of white noise,

so just think, out of all the possible numbers (sound files), what portion of them are noise? (!) .

It is important to realize that the musical number explored in this instructable is

not the only one, and this is not the only method I have invented or will invent

of generating digital sounds. Many are not yet impressed with my 3D projection

system or writing style, but at least I've included older projects which may be

reason to anticipate more and better in the future.

There may be inconsistent flow in the development of this prematurely published

instructable. I provide a link to what part of the Musical Number sounds like as

output by the device I'm now making for you to make.

Some 2^(2^(17)) digits of The Number (compressed into mp3)

Listen carefully for beats, voice like sounds (woo!) , bells ... some imagination maybe required!

I'm expecting the finished circuit to consist of a few logic chips, (no uC or uP)

so you'll need a soldering iron, a speaker, and chips which I haven't chosen yet.

You may feel free to experiment with the calculation and playing of numbers as

sound files while I work on making this instructable project.

Calculated BINARY numbers sound much louder as RAW or PCM

when the letter O is used instead of the number zero when stored as text.

(Otherwise you may not hear it at all.)

All your base are belong to you! (Haha. Use whatever base you want. Also,

I recommend using only the alphabet for bases 11 thru 26, or Hexadecimal will be distorted.)

The number that sings about the calculator is in ASCII (see Pandora's Box)

because it used to be in BCD, but that is not a standard (net playable) format.

I know you all laugh at my videos but I will probably demo LOTS of unique sound artifacts.

## Step 2: Please Stand by While I Make the Demo Circuit and Other Stuff.

Sorry, but this is for all of us. This is public domain.

I apologize for the premature publication but I feel I must announce

this project before the RIAA (possibly) very shortly tries to own it. OK, OK, now!

Oh what a mess.

Well , the main reason it's a mess is because of the way they made the chips.

It's going to be hard to draw the schematic, but meanwhile I'll be very simple about it.

Now why would you want to build this?

You can hear what it sounds like with the mp3 on the previous step.

It doesn't need to be messy, and it's very bendable.

In fact, if I break the rules and use a programmable chip, and remove some of these,

we can play the "calcul8" song and as much other music as can fit on an

i-Pod, and it MIGHT even sound as good or better than mp3's. I won't claim that

anymore until I demo something like that.

## Step 3: More Theory on Musical Numbers

HEADACHE WARNING: MATH AHEAD.

You might want to skip this step for now unless you really want or need to know.

The number being explored (zero point one two three four five six ...) is normal.

Normality is actually NOT optimal for musical numbers, and in fact by avoiding

normality, a lot of white noise can be excluded. And it's convenient to put the

white noise beside another trash bin which I call the set of impossible sounds.

The impossible sounds are playable, but have been known to damage certain

kinds of speakers. I think I have a picture, which I will post if I find it.

WHOA! Damaging speakers? If you have seen the calcul8.txt file in a sound

editor, the off-centerness has something to do with it. ...9999999999... is a Very-

Bad number because it could heat up the speaker and push the cone out!

And you might not notice, because it might just be quiet and start smoking.

Don't hook up any of my Pandora's Boxes to your really expensive audio

gear. Transistor radio speakers like the ones in my Magnet Phone instructable

won't mind the 9's as much, especially since they are used with cheap amps.

Since I'm still talking about using human numbers which can be seen in The Number,

I'll mention this other fact about The Number:

It is not only normal, but it has an average digit of 4.5.

4.5 is the middle of the numbers 01234.56789 .

The Number (I'm calling it that because sooner or later most of what I write about

it gets removed from search engines, and since I've noticed that, it doesn't hurt

to be paranoid, whatever the reason is for why that happens.)

The Number (this is what the math whizzes will object to) offers not much in the

way of advantages as a data source, except that it doesn't need the enormous

amount of memory that would be able to store it.

The Number seems to require even bigger numbers to access all of the data

in it, but only at first, and then it seems to require ones of similar or slightly

smaller size. In other words:

THE MATH FOR USING THE NUMBER AS DIRECTED

APPEARS TO WASTE IMAGINARY MEMORY.

As long as the memory is imaginary, maybe we don't have to care.

Wait! What's imaginary memory? An example is the multiplication table.

I'm not just talking about what was memorized in elementary school,

but the infinite plane of all numbers multiplied together. A computer

does not have to store that anywhere, nor could it, to retrieve the

answer to a multiplication.

Neither does The Number need to be stored anywhere.

Neither does it need a decimal point. Only whole-number math is

necessary to access it.

Now let's go back to throwing away the noise in The Number.

I'm going to work with this number as long as it takes to teach the theory.

MUSICAL NUMBERS SHOULD NOT BE NORMAL.

MUSICAL NUMBERS IN "THE NUMBER" SHOULD HAVE MORE 4's and 5's.

If you found, tried, played, looked at the "calcul8" number mentioned elsewhere,

you would have noticed that it has a lot of 4's and 5's, and is Not Normal, and

probably has an average digit of 4.5 unless it's been modified or corrupted.

I shouldn't do this just yet, but there is a smaller, more musical number with

all the music in it than The Number, which is much more likely when a long

number is pulled out of it, will have an average digit of 4.5, and will have

much less white noise. Imagine how many numbers are removed from The

Number (as if it were made by counting, which is unnecessary, just easy and slow)

and how many numbers don't have an average digit of 4.5. MOST DON'T!

I shouldn't go beyond The Number just yet because it's probably still blowing

your minds that this number is infinite, and contains all possible sounds near

the beginning of it. And that counting is the slow way but math is the fast way

to find and pull sound out of it.

How slow is counting to a musical number you recognize as a song?

The fastest computer couldn't have done it if it started at the beginning of time!

How fast is the math? Quite reasonable. Some multiple of the time it takes

to do a memory test. No musical number will ever be bigger than if you

filled your memory with ONES, as I think I explained earlier.

Unfortunately, the project this instructable is or will be about building is

going to start with counting because it's easy. But I hope it will not

disappoint. I will try to stretch it a little with some interesting circuit bending,

or alternative enumeration of the sound.

Enumeration: The order in which all these sounds are sorted.

There's a first sound, a second sound, a third sound...

and we can change WHO'S ON FIRST!

I may hear new things too. I expect to be surprised by any new alternative enumerations.

And we're still just watching Sesame Street and learning to count ... SOUNDS!

Still makeing... sorry for the delay... and that "my brain is about to explode" feeling.

(Nope, now it's done, now to "explain away" the big mess!)

## Step 4: SIMPLE OUTLINE OF THE CIRCUIT

This basically is supposed to show how the circuit simply counts

and the rest of it just reads out the digits of each number into an amplifier,

before the next number is counted. And what's under the mess of wires on my board.

Each number is a sound, just like Calcul8.txt (pocket.wav) is a number and also a song!

## Step 5: Helpful Chip Pinouts

Here I simplified the pinouts of the chips so when anyone makes this

(including myself before I made it) they can have something to look

at and not get confused by the mixed-up pinouts.

These chips can run on from 3 to 9 volts, not only 5 volts.

It's recommended that each one has a 0.1 uF capacitor across the power

(even if I don't include it in the schematic).

I'm having minor trouble with the schematic(s) at the moment, but no worries.

I might just do it by hand.

Besides that, what I will soon add is some comments on the circuit bending potential

of this circuit, and I hope I get around to video-demonstrating all the other circuits I have

made that pull digital sound and interesting noise out of thin air, or subspace, if you will.

Subspace? Ok, like fractals. How much memory would it take to hold the whole

Mandelbrot Set? Infinite. Although number "zero point one two three - infinity" is an infinite

fractal, only a finite amount on the small end is needed for all the free audiovisual stuff.

## Step 6: Finishing Up?

You might be able to build it now without my schematic,

but if not, don't worry, I'm drawing it now, and working

on my video demo. This one will be made on the old junk,

the cool analogs, because I know Movie Maker is just a

silly pain in the butt. I don't buy stuff I MAKE it!

One thing remarkable about this current "1971-tech" demo

that this instructable is going to show you how to Make is

that it seems to generate ALL THE BEATS, if not all the tunes!

Getting the tunes involves some weird math, but not too weird,

because "zero point one two three infinity" is simple arithmetic

that just requires a calculator with a million digits.

It would take billions and billions of years to hear every sound,

but any one can be downloaded from "the multiplication table"

faster than the speed of light!

THIS IS MY IP. NO ONE EVER DID THIS THIS WAY BEFORE.

As I said before in P-Box #1 and again, IT'S "FREE"!

What am I showing you? In Kindergarten terms, you just learned

to count, and therein is the sum of all human knowledge!

Sorry for the delay on the full schematic and video; I hope it's short.

Maybe I'll drop a few ACME Looney Tunes products on the RIAA in my demo video.

## Step 7: Breadboard Schematic

For a few hours this looked ridiculous without the schematic.

It's a rough one, still being checked at this time.

Check back every once in a while for updates.

Teaser: Gray Code enumeration: It moves along the edge of a cube of

dimensions equal in number to the number of bits. To bend this into

gray code without programming, you would need 32 XOR gates.

Perhaps you would prefer the PIC code, as in the original P-Box...

This has too many wires!

QUICK BENDS:

If you build this and get tired of how it sounds, I recommend mixing up the

"blue" wires on the 4040 next to the 555.

The 4051 wire order isn't as noticeably significant.

Removing one or two "green" wires from the last 4051 maybe interesting,

which I did backwards by building the circuit with power on it.

And of course, turn the playing speed knob.

The "green" wire on the left 4040 pin 1 is a reset trigger that "never" resets.

So move that reset wire to other pins and expect major changes in the sound.

I'm concerned about the 555 going too slow, but IF that happens

(making only low pitched sounds at all speeds)

try changing the 555's capacitor from 1nF (0.001uF) to 100pF.

The 555 was not tested in the circuit, I used a 4060 instead.

It will work though. Like in my hypnosis glasses instructable.

One advantage of this no-brain "mess" circuit is the convenient bending possibilities.

The following is the last sound I created on a PC immediately before that PC was

wedged in the keyboard (remote controlled) by an illegal DRM hack and rendered

useless, and is the first STEREO one generated by a process which could be

emulated by a circuit with 4 times as many of these chips; and although the

sound is open-ended (cut off at the end), it shows more synth-like qualities

than many of my other "Music-Ex-Nihilo" (P-Box) experiments.

Last PC generated, First Stereo P-Box sound from 10/2005

It's equivalent to output of a hardware bend, with diagonal orthogonal counting on 3 axis.

It also was done with a 256 bit counter. Remember, the counters are experimental only,

and impractical, since it will take forever to get to any serious music. That sound filled up

my hard drive needlessly, and reached the "convenient" limits of the PC to do this stuff.

(But more chips in the pattern below could have done it!)

A few million bits requires some obscure simple arithmetic (a Pythagorean Mystery)

to make all songs. There is a solution, which I will publish as P-Box #3 when it is made

understandable. Understand this, that THE NUMBER is only the simplest to understand

number that is useful for this purpose. Numbers can be defined for any similarly

special and amazing purpose, and as I mentioned before, the simple obvious

number is not ideal but easy to understand...I HOPE.

This is the schematic drawn from the breadboard on Step 2.

I mentioned before it's limited to 32 bits, unless you add more chips.

Twice as many chips gives 64 bits.

Eight times as many gives 256 bits. If you got the chips, the sky's the limit.

## Step 8: What's Next?

No time for secrets if you can learn them.

I owe ya all a schematic replacing the code to P-Box #1,

and the code to replace all the wires in P-Box #2,

and whatever P-Box #3 will look like.

And more bends, perhaps a drawing of a good bending panel.

Another bend: any available sound effect boxes added to the audio output.

Note:Delays or echoes are equivalent to the audiovisualized XOR2.MOV link on P-box #1.

P-Box #3 involves a number that excludes impossible sounds and requires less

"imaginary memory". Notice the imaginary memory in the schematic in step 7,

whereby gigabytes are pulled out of nothing. There is an intangible ROM (imagine it

as an invisible disc made of nothing) being played. The sound format is slightly

foreign to PC's, after all, if a text number can sing (calcul8.txt or pocket.wav),

but your OS doesn't recognize it as playable in spite of it's simplicity, well, this

is what challenges me. Calcul8.txt and Pocket.wav play better and equally well

on raw electronics or logic which is not programmed to reject ANY data!

Time to "take an aspirin" again. (Joke, not medical advice. HARD STUFF AHEAD.)

I want to show you something weird, related to artificial intelligence.

I say it's related to artificial intelligence because I've already pondered whether

such numbers can play tic-tac-toe, checkers, and chess. One number apparently

can play all three. It can play a perfect game if such perfect games exist, and

even without being aware of which game it's playing. This hasn't been done, but

sufficiently simulated that it's known to be cleverly cheatable... you can steal it's

game-pieces and it will not notice even though it still may win. Putting extra queens

on the board may or may not produce unpredictable results. I'd expect a "new game"

response or a "blank board response", not ambiguous ones. An example of an

ambiguous response to an impossible board would be all pieces changing to queens,

or the whole board being filled with them.

Perhaps the "gameboard number" has already been calculated, as THE Method for

electronic games. Again there are other numbers,

less recogniable than "zero point one two three" with similar (musical) or different uses.

It IS artificial Intelligence!

Once it was common to use binary to decimal converter chips, but there was an odd

possibility: The binary input could go up to 16 but the decimal output had no

sensible response to anything 10 and above. I call this AMBIGUITY. Look at

what happens on the readout when the binary input exceeds 9.

Similar anomalies result when an artificial intelligence (neural net) is taught

more than it can learn, and is quizzed on something... I've seen them make stuff up!

I don't know about you, but if I see a sign, and it's in a language I haven't learned,

and the letters don't look familiar, my mind is definitely not silent; it reads the

sign and I hear a strange noise in my thoughts! (Certainly not what's written.)

So, look what a certain binary to decimal converter chip (7447 or 7448) does

when it is given a number that it can not display! It tries anyway! This unexpected

info is a BAD example of how BAD info can come from no where!

It doesn't know or care that it can't produce the numbers 10 through 15.

The output was not designed, and definitely not explained in the manual.

In the musical number theory, we actually do expect USEFUL information

to come from no where, in ways never before designed. Imagine that your

computer came with 1 gigabyte of RAM but some was partly defective, so

you removed it, and are waiting for a replacement. But you have a program

that requires 1 gigabyte of RAM and doesn't check to see if it's there. That's

unlikely to happen nowadays but in the past AMBIGUOUS results have been

obtained from missing memory. Perhaps I'll demonstrate in my next video. But,

The nothing from which musical number theory pulls it's output is not this kind

of illogic. It is as I said, like a big giant imaginary multiplication table, full of answers,

but the answers are not written, until the question is asked; they just exist, made of nothing.

There is nothing that can be computed tomorrow that can't be computed today!

Am I beating the dead horse?

THE NUMBER already has in it what you will record tomorrow.

Again, look at the illogical output of the binary to decimal chip.

I'd have either made 11 look like 11 at least, or included hex AbCdEF.

But the chip was NOT designed to make what it makes, as if no one would

ever count higher than 9. This example is interestingly AMBIGUOUS, but useless!

Information from no where, but useless info. No, this is not what we do!

## Step 9: What's Next , Continued.

Again, this is the plan for the near future.

1.Tie up loose ends, by adding more hardware and software alternative equivalents.

(There are many ways to make the sounds)

2.Make a documentary and tutorial video of this technology.

3.Continue the P-Box "series" and hope enough people understand the "lessons".

(This involves simplifying the weird synthesizing processes to a reasonably makeable level.)

4.Lead up to a simple useful makeable All-Music-Box and other similar instruments.

5.Explore other uses for These Things. There are very many more hard to believe uses.

6.Miscellaneous arts and works.

No hints now about the future "Boxes",

except (and also because) they get progressively better and more advanced,

but not much bigger.

## Step 10: ORIGINAL PANDORA'S BOX CIRCUIT

This one has been struck twice by anomalies, and now is in an unbelievable condition.

One difference: I used a 1.842000 crystal.

UPDATE: ***It has just been found that there is an error in this schematic,

and pins 9 and 10 (upper right pair) are reverse connected on both 4040's. ***

## Step 11: A Demonstration of a Musical Number From THE NUMBER.

This Musical Number describes the process of it's own creation!

-Look at the number in a word processor to verify that it's only "just a number".

-To hear the sound of this Musical Number, it must be imported as RAW 8bit unsigned mono pcm

into a sound editor at the well chosen rate of 8000 samples per second. This was decided long

before PC's had sound, when programs were stored on compact cassettes and 5 inch

floppies. While playing, the sound must be turned up due to the inappropriate hardware.

-This is the only sound represented by Musical Numbers thus far which is for the purpose

of showing that any given or any future sound can be calculated by simple arithmetic,

which sounds like a song which you may be familiar with. Since Musical Numbers are not

a standard sound format, this will not sound as good on a PC as on logical hardware, such

as circuits made with chips in the schematics already given, so listen with higher volume.

-Fact: "human" Musical Numbers were invented on an Atari 400 and used to give human

(non-robotic) voices to devices used by blind people, after several years of being a

human voice synthesizer novelty.

## Step 12: Gray Code, Another Musical Number Counting Method

Gray code is one of many alternate methods of counting in binary,

usually the one which walks around unit cubes and hypercubes of

any number of dimensions, these dimensions being the powers of

the digits in a musical number.

The most common gray code is translated back and forth by the

integer formula G = N XOR N/2 (N = G XOR G/2).

Working with 0.123 type numbers in gray code is not convenient,

and the number 0.123 (123...) converted to gray code is not very

musical sounding to me. But it does seem to be useful for grouping

musical numbers together in an order. Recent experimental calculations

show that skipping numbers and converting them to gray code will

generate all the musical numbers, at least short ones. For example,

counting to 16 using even numbers and converting those even numbers

to gray code will generate all 6 4-bit "Musical Numbers".

Number,Even?,Gray,Musical?

0000,yes,0000,no

0001,no,0001,no

0010,yes,0011,YES

0011,no,0010,no

0100,yes,0110,YES

0101,no,0111,no

0110,yes,0101,YES

0111,no,0100,no

1000,yes,1100,YES

1001,no,1101,no

1010,yes,1111,no

1011,no,1110,no

1100,yes,1010,YES

1101,no,1011,no

1110,yes,1001,YES

1111,no,1000,no

A "Secret" loosed: Musical numbers in Binary are permutations of a square wave,

(combinations of an equal amount zeroes and ones)

where for every zero there is a corresponding one. (Average bit = 0.5)

The stream equivalent of Binary Musical Numbers include Delta and PWM.

Gray codes may be a good method for locating Musical Numbers faster,

but they do not reject Noise and Silent Numbers. Images included on this

instructable page:

Gray code converter for Bending the champ counter,

The gray code "cube walk",

The tesseract hypercube (all dimensional hypercubes can be walked in gray code),

(Look for the 8 regular cubes which are the sides of the tesseract!)

It appears that hypercubes can be rotated so that all the Musical Numbers

"Appear to align in a straight line between the "poles" between 0 and "all ones".

Summary of this lesson: No matter how "big" a number is,

you can always find a way to calculate or count to it.

The Gray code example is given for small numbers,

but a million digits or dimensions are no big deal (or won't be in the near future!).

## Step 13: How to Count Only Musical Numbers

This is in english but for the purpose of making an algorithm in any program language

or for making a circuit.

First, an example:

The 20 six-bit Binary Musical Numbers in 2 columns.

000111 100011

001011 100101

001101 100110

001110 101001

010011 101010

010101 101100

010110 110001

011001 110010

011010 110100

011100 111000

Notice that binary can count to 63 with 6 bits, but only 20 are "musical",

(by my definition , or physically sound-like). The ratio of musical to total

numbers decreases incredibly as the number of bits goes up. Therefore

they are very countable. Not infinite. In fact, each has a double that

sounds exactly the same all bits different in the other column (which

need not be in another column, just to save 10 lines).

Notice that at the beginning, the count has all the ones on the right,

and ends with the ones on the left. It just so happens that the number

of Musical Numbers for any number of bits is equal to the number in

the middle of the row of Pascal's triangle whose row number is the

number of bits. This is a fascinating unique science.

Ok, one rule for counting this way in binary is:

00001111

Start on the RIGHT and go LEFT until you find 01.

Change that 01 to 10, and push any other 1's you've passed all the way to the right. Stop.

You now have the next musical number.

Do it again and again until all the 1's are on the left side.

11110000

If you are using a circuit, you may bend it by mixing up the bits before and

unmixing them after each count, as simply as "not wiring the bits in the right order".

In a program, you might have a SWAP instruction, or an arbitrary lookup table.

Why? To make really weird counting patterns that sound different.

Another Secret :

TO AVOID COUNTING, You can calculate any sound instantly by remembering

it as a polynomial, and having "the calculator" evalulate it, and then,

Use the combinatorics function "N Choose R". THIS WORKS IN ALL BASES.

What's the trillionth sound that fits in 4 megabytes? Bam!

Boo! (-The ghost of "napster"!)

It's raining ACME anvils, pianos, and dynamite somewhere now, what a beautiful noise!

## Share

## Recommendations

We have a **be nice** policy.

Please be positive and constructive.

## 70 Comments

Fascinating - I've been playing around with Champernowne's number in various bases on a PicAxe and interpreting the digits as tones in a musical scale. It's beginning to sound quite musical.

Just wondered if you'd seen THIS. This guy's been interpreting The Number as text strings and he's been locating published passages within it. He's located a passage from Genesis and a Shakespeare sonnet wayyyyyyyyyy down the sequence. It's all there - it's just a case of finding it.

Thanks for the link and your interest in this number and project. The link is especially nice because it has another set of instructions for calculation. I do not recall exactly where I

postedmy equations at the moment, which are simple arithmetic. In the future I hope to publish more of this kind of thing.This is not rocket science, just some lateral thinking. I think the reason that people may find this difficult to grasp is the way it has been explained. Try this explanation... as an example, music stored in CD quality format uses 16-bit samples, sampled at 44.1Khz. One second of sound therefore is stored as 44,100 times 16 bits. In binary, you can look at this simply as a very large number, rather than a stream of bits. Now, thinking in reverse, suppose you have (any) number, converted to its binary representation (a string of 1's and zeroes) and fed that to the D/A converters of, say, a CD player then you would hear 'music'. A number converted to binary may not necessarily be a Top 10 hit though! :) So, you can imagine an entire track of a CD as a single number (represented in binary by the bit stream). An infinitely large random number, represented in binary as an infinitely long string of bits would therefore contain all the musical combinations possible (as someone pointed out with the monkeys and typewriters analogy). So, for a given music track, normally stored as a binary bit stream, you COULD represent that by a single, large, number. If you represent music in this way, all you need is a circuit that takes a number and generates a bit stream to feed to a D/A converter. The inventive step required is how to represent 'the number' in a form that doesn't require as many bits as its binary representation - otherwise you may as well store it as we do today on CDs.... as a binary bit stream. The easiest way I can think of is in analog electrical form, as analog circuits are continuous, not discrete sample like digital, so you can represent any number to any precision (which is necessary to obtain sufficient digital bits for playback). Ah well, thats my contribution :)

Attention programmers:

Why not write a program that rips CD audio as a single number, then perform prime factorization to compress and store the data? Or, using the same algorithm as this instructable, find the starting position for playback so all the computer has to do is pick the math up at that decimal place to begin reproduction?

It seems to me like the original number crunching might be CPU-intensive, but then encoding an MP3 or any other file compression tends to be taxing too. Aside from that, if the result was expressed as powers of 2 or 10, it might be tidy enough that the execution doesn't take so long.

If stored as an exponent, maybe the ripper could add a trailing silence to the audio. That way, the exponent could be fudged a little to make it easy and a bit smaller, and it would prevent audible errors on the other end.

Perhaps a low-quality MP3 or .wav file might be a good starting point, just as proof-of-concept and to keep the math from taking forever during development.

As Viron has suggested in the past, this is a helluva way to bypass DMCA. Who can bust you for sharing numbers? Maybe as long as you have Prime 95 installed on your computer you could just say you're testing Mersenne primes for musicality. Who knew

2

^{98749819378786574298842008-1}sounded like Metallica?

Lars Ulrich: "Now those f*ing math geeks are stealing my money! How am I supposed to f*ing pay for my gold-plated tennis racquet? I'm gonna f*ing sue you, math!"

James Hetfield: "MATH BAAAD!"

"Why not write a program that rips CD audio as a single number, then perform prime factorization to compress and store the data?"

A friend of mine had the same idea (but for compression of arbitrary data, just find the place in pi where the bitstream occurs and record that). There are two main reasons:

a) storing the location of where an arbitrary pattern occurs in the bitstream requires as much storage as just storing the pattern. Think of the generated stream 01101110010111011110001001101010111100110111101111 etc, which encodes

0, 1, 10, 11, 100, 101 etc.

If you want to store an 8-bit pattern, the only place it is guaranteed to occur is in the "8 bit patterns" chunk of the stream or later. This part of the stream starts after 128 bits of the bitstream, so to encode a location that far into the stream requires... 9 bits.

b) Let's call a CD 60 minutes of 44000 Hz at 16 bit sampling rate. That's

60 * 60 * 44000 * 16 bits

= 2,534,400,000 bits. The number that this therefore represents is of the order of 2

^{2,534,400,000}Given that the largest known prime is of the order of 2

^{43,000,000}, which took the Great Internet Mersenne Prime Search many months to find, the prime factorisation of the "CD number" would take a very long time indeed.Figuring out why this sort of approach

doesn'twork tells you a lot about information theory, but for practical compression you are better off looking at the actual data and what redundancies it has that you might be able to exploit.Well, I wasn't thinking about applying this to an

entireCD - perhaps more like a 3 minute song. I know, even still this would be a difficult feat, but perhaps breaking the song further into smaller chunks would yield better results. Using your method of finding "pattern chunks", a 24-bit vector could contain the starting location for a 10 second clip of audio at CD-quality (44100 samples per second at 16-bit depth and 2 channel stereo).Given the fact that even high-quality MP3's and AAC files lose considerable resolution to compression, you could even possibly truncate the 16-bit sample depth to 12 bits for a compromise, thereby decreasing the amount of heavy-lifting necessary by a total of 8 bits in the starting vector.

I don't believe it would really compress audio so much as offer a way around DMCA. Although it technically doesn't create a loophole, it still gives a more plausible excuse. Let's say someone created a program similar to Prime95, only it processed a data stream (could be audio, stock market fluctuations, any data you decide to throw at it) and stored its results to a generic file. Those files could still be traded under the guise of scientific research. If you combine those files at your end to recreate audio - it's your thing, do what you wanna do. I can't tell ya who to sock it to.

I mean, I'm sure I can create some permutation to turn my Windows .cab files into a .jpg of Mickey Mouse. Will Disney sue me for violating their copyright by transforming existing, unrelated data into this photo? Or will they sue Microsoft for creating code that can do so? Or perhaps they'll sue math itself?

The main point is still the same: storing the location of a pattern in a known sequence takes just as much information as storing the data itself. Regardless of whether you're going to rip an entire CD or just a 3 minute song.

Regarding copyright, just transforming the data isn't enough. If it were, there would be no way to prosecute people for sharing MP3s (as MP3s are significantly abstracted from the original audio data). In court, it comes down to prior knowledge: if you can prove you haven't heard of Mickey Mouse before, and you just happened to transform your .cab file into this funny looking cartoon character you would like to use for marketing purposes -- then you're good to go.

I disagree with your first point. Mathematically speaking, if you find the starting point for a known sequence and express it exponentially, it will take significantly less space to express it. To be precise, the greater the number of the starting point, the higher the compression ratio becomes.

Bear with my explanation for one moment:

Audio signals fluctuate. Assuming that the lowest frequency expressed by a given signal will be approximately 20 Hz (the low threshold of human hearing), it is reasonable to assume that the file to be analyzed would not carry a DC component for greater than 0.025 seconds (which, if it were DC for that period, would represent either the crest or trough of a 20 Hz square wave, assuming a 50% duty cycle). This means that we can rule out certain exponentially expressed numbers that, when expanded, create a DC output.

While this would eliminate 2^n (the simplest to represent with n being the total length of the audio in bits), it would also eliminate 2^n-1 (the most costly to represent). It would also rule out any starting point that gives you a few cycles, then DC. Really, this logic excludes roughly half of any given possibilities for expressing such a number this way.

Computationally expensive, absolutely. I'll give you that. I never was much of a programmer, even in my Commodore 64 heyday. But I can tell you that such a compression scheme is feasible, and it would significantly reduce the amount of data required to reconstruct audio.

As for copyright: after I posted my previous comment, I researched and found that there are, in fact, illegal primes. A few were constructed by some guy who decided to take DVD cracking software and throw the right combination of bits at the end so that it would be a prime number. Using this number, you can unzip the software. Apparently, it's illegal under DMCA not because it's a numerical representation of software, but because it contains software that is designed to decrypt a copy-protection scheme. It appears there's still no legal precedent for a numerical representation of anything like I'm suggesting, as it still falls under the "fair use" test. So, if I find out that Metallica's "St. Anger" album can be reduced to a handful of powers of two, hooray for me. If I use that to upload the album to Limewire, I'll still have Lars Ulrich's lawyers suing me for money they didn't make by selling the album.

Nevermind the fact that sounds like Hatebreed, but with less talent. No, that couldn't possibly be why no one paid for a copy.

I'm not sure quite what you mean by your first paragraph, but my core assertion is still valid- storing the position of an

arbitrarybit pattern in a generative stream takes at least as much information as just storing the bit pattern. Information theory imposes that hard limit, there's nothing you can do about it.Where your idea does become feasible is where you start examining this idea for music compression, not arbitrary data compression (because you can't actually compress arbitrary data, only data containing some redundancy). Your assertion that most "chunks" of music will fit a certain pattern (frequencies between 20Hz and 20KHz, no DC component) is completely true. The obvious way to utilise this is to arrange all the possible chunks of a given size in order of "likelihood to arise in a piece of music", so the common chunks are at the beginning of the pattern so take less information to encode. If the first half of your track sounds like Lars Ulrich, the probability of more Lars Ulrich down the line is greater :)

This will only give you a slight compression, because you are still reproducing the music precisely (a.k.a. lossless encoding), but if you are also willing to say "well, this chunk from 2/3 of the way down the bitstream is actually very similar to chunk number 6 right at the beginning", hey presto, you are trading a loss of a small amount of reproduction accuracy for a much bigger reduction in size.

This is, not coincidentally at all, similar to the way I believe MP3 compression works. It's certainly quite similar to the way JPEG encoding works, but I only did computer graphics lectures not computer audio so can't be certain.

At this point I suggest you read up a little about lossless vs. lossy compression, JPEG, MPEG, wavelet encoding and the related fields, because

a) what you find will probably have been written by people better at explaining things than me

b) it's a fascinating field. For instance, it turns out that your nervous system between your eyes and your brain uses a similar type of encoding to JPEG images to compress data. Who knew?

Concerning the DMCA, illegal primes etc., I think it's the spirit that matters (and will be taken into account) rather than technicalities. If you end up with an audio file of copyrighted music you didn't pay for, it's still piracy whether the intermediate transfer was done with MP3s, prime numbers, vinyl records attached to carrier pigeons...

Not to beat a dead horse, but I'll make a second attempt as it was past my bedtime on the first try and I think I fizzled out about 1/16 the way through.

Let's assume that we have written a simple program that takes 2^n and turns that calculation into a bitstream. Now, if n=2, the bitstream outputs 4; obviously, there isn't much compression happening because n takes two bits to express, while 4 takes three bits. However, if n=256, the bitstream outputs 65536. This is a considerable savings, as n is only 9 bits long while the bitstream is 17 bits long. The savings continues to grow as n gets larger.

In searching for a real-world example, let's try creating a starting vector for 10 seconds of CD-quality audio. That's 16 bits/channel, 2 channels total, at 44100 samples/second, for 10 seconds. 16*2*44100*10=14,112,000 bits total. To find out how many bits long n would be, we simply find log2(14112000)=23.75, or 24 bits. This is the starting place you mentioned before, where the "10 second audio number" lives.

In practice, we would actually take the 10 second bitstream and perform a log2 to get n. However, in a real-world example there will still be a remainder. So we continue to perform log2 to this number to get another, and so on, until we end up with 0 or 1 at the end.

Another possibility is to compare the result to the original block of audio and find out how many seconds it takes before there is an inconsistency. Then, one could pick up at that location with another 10 second block and continue until the routine reaches the end of the audio file. At that point it would follow the example of the previous paragraph.

The point I feebly attempted to make before is that, while we couldn't hope to do this only one time, we also shouldn't expect to have to do this 14,112,000 times per block either. This means that the resulting file of "n1+n2+n3+..." should still be significantly smaller than the original, at least from what I'm guessing.

I would have attempted this program a long time ago to see how successful I'd be, except I haven't programmed since the late '80s. I do know that log2 is a simple calculation to make, even on very large numbers, so it wouldn't surprise me that this could be pulled off fairly quickly - however, I know it could possibly be expensive, as it would take many iterations for each block of audio.

I am aware that there can be a gaping hole in my logic here, as math was never my strong suit. However, I would like to see good proof that I'm wrong. If I were pursuing free energy, I'd expect to be told, "You can't break the laws of thermodynamics, you kook!" If you could describe to me how there is a hard limit here, I'm all ears; however, right now I can only see the limit as a theoretical maximum, not as a law that it will take exactly as many bits to describe as the number one would describe with them.

Excellent. And you did it in one paragraph.

I convertered your breadboard schematic to a more logic electronic schematic which also makes the circuit more understandable. But either I'm not fully understanding the concept or you made a mistake in the schematic because as you can see on all the 4051 chips I/O 4,5 & I/O 6,7 are twisted. (though I doubt It will make a big difference in sound) I also took the liberty to convert the original pandora circuit to another schematic and except for reverse connecting pins 9,10 I think you also forgot to connect I/O 8/9/10/11 to the output. I build this circuit (with all the I/O connected) and it sounds nice though It's clearly a repetitive counting sound. But It's a very nice concept.

Just a note about why BCD --> 7-segment decoder chips usually ignore 10-15. BCD is an abbreviation for Binary Coded Decimal. In decimal, the only valid digits are 0-9. Every unique output state that must be defined requires logic gates to implement. Every gate cost money to produce. When designing the chip, only 0-9 had to map to some specific output. When the engineers optimized the design to minimize the number of gates, they didn't care what happened to the output lines for invalid input. Any definition of those output states would have required additional gates. This is why different manufacturers chips often produced different results for those undefined inputs. The logic array was optimized in a different manner using a different combination of gates. Within the defined states, they behave the same way, but not in the undefined states. There are hexadecimal --> 7-segment chips. They cost more (at least they used to).

Fun. I did this in software recently with notes in an octave, but am working on something lower level now. http://vimeo.com/1569824

... Um yea...

Thanks for the maths, and complex explanation, but I want something really simple here. Your device counts upwards and outputs as a sound? Reply will be met with further inquiry.

[quote]Wait! What's imaginary memory? An example is the multiplication table.

I'm not just talking about what was memorized in elementary school,

but the infinite plane of all numbers multiplied together. A computer

does not have to store that anywhere, nor could it, to retrieve the

answer to a multiplication.[/quote]Actually, processor chips

*do*store all the numbers in a table and look them up when they have to do multiplication. It also works backwards for division. It's faster than actually doing the maths the way humans do it.This is how the infamous Pentium Bug happened - the chip designers thought they could remove, sorry,

optimise furthersome of the values, and the result was that the look-ups were then wrong.http://www.maa.org/mathland/mathland_5_12.html

That is an exceptional Defect of the Pentium in particular. Most processors certainly do Not work that way.

Actually, all full modern chips have this look-up table. It used to be stored in a discreet chip, which was a maths co-processor, but now Pentium level and above (Intel, AMD and IBM) all have them built in. Wasting a few cycles to work out a single division would be silly when a single call to a register burned onto the chip.

Math coprocessor units are not lookup tables. They are calculators. They use floating point math which only works with small numbers. Almost "all full modern chips" do NOT have math coprocessing. And most of the chips Intel,AMD,IBM make are not for PC's. Some DSP and RISC chips have single cycle mul or div operations.