• Character sets (ASCII & UNICODE) give every character on your keyboard a unique binary code.
• ASCII uses 7 bits (128 characters) — good enough for English, useless for most other languages.
• Extended ASCII uses 8 bits (256 characters) — adds a few extra symbols.
• UNICODE uses a minimum of 16 bits (65,536+ characters) — covers every language and emoji on Earth.
• Sound is analogue in real life, but computers need it digital — this conversion is called Analogue to Digital conversion (A2D).
• Sample rate (Hz) = how often the sound wave is measured per second.
• Sample resolution (bits) = how much detail is stored per measurement.
• Bitmap images are grids of pixels, each pixel holding a binary colour code.
• Resolution = total number of pixels (width × height). Colour depth = bits per pixel.
• Across the whole chapter, one rule keeps repeating: more detail = more bits = bigger file.

Deep down, a computer has no idea what a "letter" is. All it can store is binary — strings of 1s and 0s. So if you want to store the letter A, everyone (every keyboard, every screen, every app) needs to on which binary pattern means "A". That agreed-upon list of characters and their binary codes is called a character set.

Think of it like Morse code. Dot-dot-dot only means "S" because everyone using Morse code agreed on that mapping beforehand. If your computer used one mapping and mine used a different one, the moment you sent me a text file it would come out as gibberish — that's exactly the problem the chapter's PDF points out: without a shared standard.

Character sets are also ordered logically — the code for 'B' is exactly one more than the code for 'A', 'C' is one more than 'B', and so on. This is genuinely useful: it means a computer can sort text alphabetically just by comparing the binary numbers, and it can figure out that lowercase and uppercase letters are related by a simple fixed offset.

The number of characters a set can represent depends entirely on how many bits it uses per character. This is just the maths of binary: with bits you can make 2ⁿ different patterns, so 2ⁿ different characters.

ASCII (American Standard Code for Information Interchange) was one of the earliest accepted standards for representing text. It uses 7 bits per character, which gives:

Those 128 codes cover uppercase A–Z, lowercase a–z, digits 0–9, punctuation (!, @, #...) and some control characters (like "new line" or "tab"). That's genuinely enough for basic English — but nothing else. No accents (é, ñ), no non-Latin alphabets (Arabic, Mandarin, Cyrillic), and obviously no emoji.

Notice something neat in the table from the notes above: a is 97 and A is 65 — a fixed gap of 32 between every uppercase/lowercase pair. This is a direct result of ASCII being "ordered logically" — it's not a coincidence, it's baked into the design.

UNICODE was created specifically to fix ASCII's biggest weakness: not enough room for the world's languages. It uses a minimum of 16 bits per character:

With 65,536+ codes available, UNICODE can represent virtually every alphabet on Earth — Latin, Cyrillic, Arabic, Chinese, Japanese, Korean, and more — plus modern symbols like emojis. This is why, when you send an emoji in a text message today, it displays correctly no matter what device or country the other person is in.

Sound in the real world — someone's voice, a guitar string — is an analogue wave: a smooth, continuous signal that can take literally any value at any point in time. Computers, on the other hand, can only store discrete binary numbers. So there's a mismatch: how do you turn a smooth, continuous wave into a series of binary numbers?

The answer is a process called Analogue to Digital conversion (A2D). The idea is simple: instead of trying to capture the continuous wave (which is impossible), the computer takes lots of individual snapshots of it. At regular, tiny intervals of time, it measures the amplitude (height) of the wave at that exact instant. Each of these individual measurements is called a sample. Each sample produces one number, and that number can be stored in binary.

String enough of these samples together in order, and you get a "staircase" version of the original wave — not perfectly smooth, but close enough that when played back (reversing the process — Digital to Analogue conversion) it sounds like the original.

There are two separate "dials" you can turn to control how accurately that staircase matches the original wave: sample rate and sample resolution.

Sample rate is simply of the analogue wave. It's measured in Hertz (Hz), where 1 Hertz = 1 sample taken per second.

Real-world examples help this stick. Old analogue telephone lines sampled sound at only around 16/22 kHz — which is why hold music over the phone always sounds thin and tinny. A standard music CD samples at 44.1 kHz (44,100 samples every second!) — enough to make music sound rich and full. A DVD pushes it even further to 48 kHz.

Sample resolution is the . If sample rate is about you measure, sample resolution is about you measure each time.

Imagine measuring someone's height with a ruler that only has marks every 10 cm, versus one with marks every 1 mm. Both rulers can measure height, but the second one captures far more detail. That's exactly the difference between low and high sample resolution — an 8-bit sample can only represent 256 different amplitude "heights", while a 16-bit sample can represent 65,536 different heights, capturing much finer detail in the loudness of the sound at that instant.

Both sample rate and sample resolution follow the exact same overall pattern — turning either one up improves playback quality, but always at the cost of a bigger file.

A bitmap image (like a photograph) is built out of a grid of tiny squares called pixels — short for "picture elements." A pixel is the smallest possible element of a bitmap image; you can't split one pixel into anything smaller.

Every single pixel in the image is stored as its own binary code, and that binary code is unique to whatever colour that particular pixel is. So a photo isn't stored as "a picture of a cat" — under the hood, it's just a huge, ordered list of binary numbers, one per pixel, each one saying "this exact tiny square is this exact colour."

Naturally: the more colours involved and the more fine detail in the picture, the higher the quality — but also the more binary data that has to be stored. That's the exact same trade-off we saw with sound, just applied to pictures instead.

Resolution is the total number of pixels that make up a bitmap image. You calculate it by multiplying the image's width × height in pixels.

In general, higher resolution means more detail and better image quality — more tiny squares means each one can be smaller and more precise, so curves and edges look smoother instead of blocky.

You'll often see display resolution described just by the vertical pixel count:

Colour depth is the number of bits stored per pixel in a bitmap image. It works exactly like the character-set maths from the start of this chapter: with bits, you get 2ⁿ possible colours.

With a colour depth of just 1 bit, you only get 2¹ = 2 possible values — enough for pure black & white (1 = white, 0 = black), like the pixel-art character shown in the original notes.

With a colour depth of 2 bits, you get 2² = 4 possible binary codes (00, 01, 10, 11) — so 4 colours available.

This is why 24-bit colour is nicknamed "True Colour" — with over 16 million possible shades available per pixel, the human eye essentially cannot tell the difference between neighbouring shades, so it looks like a smooth, infinite range of colour.

As either resolution or colour depth increases, the bigger the file becomes on secondary storage. This makes sense once you break it down:

• Higher resolution → more pixels in the image → more individual binary codes need storing
• Higher colour depth → more bits stored per pixel → each of those codes is longer

Because higher resolution and higher colour depth both push the file size up, there's always a balancing act between image quality and how much storage space (or bandwidth, if streaming) you're willing to spend.

• I can explain what a character set is and why it's needed
• I know ASCII uses 7 bits and represents 128 characters
• I know Extended ASCII uses 8 bits and represents 256 characters
• I know UNICODE uses a minimum of 16 bits and represents 65,536+ characters
• I can explain why ASCII is unsuitable for non-English languages
• I can apply the formula: number of characters = 2^(bits)
• I can explain what Analogue to Digital (A2D) conversion is
• I understand what a "sample" of sound is
• I can define sample rate and explain it's measured in Hertz
• I can define sample resolution (bits per sample)
• I know how sample rate/resolution affect playback quality & file size
• I can define a pixel
• I can calculate image resolution (width × height)
• I can define colour depth and calculate colours available (2^n)
• I can use the formula: file size = width × height × colour depth
• I can explain the quality-vs-file-size trade-off for text, sound, and images