Print PDF
Favorite
Email
(*)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.
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.
Remove these ads by
Signing UpStep 1More 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.
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.
| « Previous Step | Download PDFView All Steps | Next Step » |
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.
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
298749819378786574298842008-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!"
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 22,534,400,000
Given that the largest known prime is of the order of 243,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't work 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.
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?
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.
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.
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...
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.
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 further some of the values, and the result was that the look-ups were then wrong.
http://www.maa.org/mathland/mathland_5_12.html
See http://www.cs.earlham.edu/~dusko/cs63/fdiv.html and http://support.intel.com/support/processors/pentium/sb/CS-013007.htm (Last paragraph reads:
"The cause of the problem traces itself to a few missing entries in a lookup table used in the hardware implementation algorithm for the divide operation. Since this divide operation is used by the Divide, Remaindering, and certain Transcendental Instructions, an inaccuracy introduced in the operation manifests itself as an inaccuracy in the results generated by these instructions."
The reason this bug occurred was because someone thought they could further optimise the already fully optimised table by removing a few numbers that "weren't needed" but in fact were. This was to reduce the size of the look-up in the FPU.
In the era of the Pentiums, they used a faster variant of the ever-popular SRT algorithm, calculating two bits (radix-2) at a time instead of one. (Off-topic: Very recently, Intel bumped this again to using a radix-4 division algorithm in the Core 2 family, which almost halved the throughput latency of the FDIV and related operations.) A full LUT-based Pentium FPU would need a 280 lookup table, which is absolutely enormous, and unrealistic (you would need several quadrillion quadrillion bytes). By successively approximating the solution to the division until the error is too small to be represented by IEEE754 at any given bit depth (in this case, 80-bits), you can implement a full hardware FPU without having to have that enormous lookup table.
FPUs work much like we do when we go about solving a long division problem, a digit at a time (solving the recurrence relationship). After every step in the division, we calculate partial values by multiplication (CPUs use left- or right-shifts instead) and subtraction, and use the partial remainder values to complete the next digit(s). FPUs look up the next digit instead of calculating it directly to avoid the need for additional latency for this operation, much as we know that 5 will go into 15 evenly without having to go to a calculator. (Oddly enough, we happen know this because when we're kids, we are taught at least a base-10, 144-value LUT ("times table"/"multiplication table"), which happens to be really convenient when doing traditional math.)
The problem with the FPU was similarly pretty simple. The (IIRC) 1066-entry-long M*d LUT used to find the next quotient digit based on the last partial remainder (M) and the divisor (d) in the algorithm was five entries short. All of these entries contained 0, when they were meant to contain "+2". These entries were removed from the table after some engineer(s?) did some bad math while trying to prove these entries unreachable when in fact they were reachable, just very, very rarely (1 in 9 billion random operations). (Alternatively offered by some Intel-sponsored revisionist-historians was that these engineers simply "forgot to program the table with these values", however, this is exceedingly unlikely.)
So yes, it uses a LUT, but as a way of making the successive approximation algorithm faster, not to "look up the solution." You could leave the LUT out and still build an FPU, but it would be much more latent, which would sell fewer chips.
(Works on a HYDRA, may be tweaked for other Propeller Chip products.)
directly into an analog speaker.
My old CD player will play data CD's and usually make awful noise.
A musical number is like a data CD, made with math, not recording,
that sounds like music, not noise.
Here is one:
http://ultravires.net/POCKET.WAV
turn up the volume, and after listening to it, open it with
WORDPAD or some other editor to see that it is just a number.
And it is not unique. There are googols of numbers that sound
the same as that one or better.
The number doesn't represent anything like notes, but the way
the speaker and ears react to it is to sound like or hear music.
0.123... is simply the "obvious" predictable end of counting to infinity
and instantly having one (musical) number with all others in it,
ready to be played out.