Data representation: Character encoding to Data compression: OxfordAQA IGCSE Computer Science Complete Notes

Turning everyday things into bits

Think about everything you look at on a screen or listen to through headphones: a text message, a photo, a song. None of it starts out as binary. A computer's whole job in this part of the specification is converting real things, letters, pictures and sound, into patterns of bits, storing them efficiently, and turning them back into something you recognise. The oxfordaqa igcse computer science data representation: character encoding to data compression content walks through exactly that journey, one everyday example at a time.

Character encoding

A character set is simply an agreed list of every symbol a computer needs to represent, each given its own numeric code. Think of it like a cloakroom ticket system: every coat gets a number, and as long as everyone agrees which number belongs to which coat, the system works. Two character encoding methods matter here: 7-bit ASCII and Unicode.

ASCII uses seven bits per character, giving 128 possible codes, which is enough for the English alphabet in both cases, digits, punctuation and a handful of control codes, but nowhere near enough for the world's other alphabets, emoji, or mathematical symbols. Unicode solves that by using far more bits per character, giving room for a huge range of characters from many different writing systems and symbol sets. Importantly, Unicode uses the same codes as ASCII up to 127, so any text that only uses the original ASCII characters looks identical whether it is being read as ASCII or as Unicode; the extra range only comes into play once you need characters beyond that original 128.

Character codes are grouped and run in sequence, much like a street of houses numbered in order. In ASCII, capital A is coded as 65, capital B as 66, and so on, so once you know where a group starts, you can work out any code in that group by counting forward. The same pattern holds for lower case letters and for digits, each running as its own consecutive block.

Worked example: using a character encoding table

If capital A is 65, what is the code for capital G? G is the seventh letter of the alphabet, so it sits six positions after A: 65 + 6 = 71. The same logic works in reverse: given a code of 74, subtracting 65 gives 9, and counting nine letters on from A gives J.

Representing images

A pixel, short for picture element, is a single point in a graphical display. Picture a sheet of squared paper where you colour in individual squares to build up a picture; a screen works the same way, dividing itself into thousands or millions of tiny squares, and a bitmap image is stored as a record of the colour of every single one of those squares, arranged in rows and columns.

The size of an image is described as its width in pixels by its height in pixels, written as width times height. Colour depth is the number of bits used to store the colour of each individual pixel; a higher colour depth means more possible colours per pixel, in the same way a bigger box of crayons lets you shade in finer differences of colour than a box with only a handful of options. Both a higher number of pixels and a higher colour depth make the file bigger, because there is simply more information being stored.

Worked example: calculating bitmap file size

The formula is straightforward: size in bits equals width times height times colour depth, and dividing by eight converts that into bytes.

Image: 200 pixels wide, 100 pixels high, colour depth 8 bits
Size in bits = 200 x 100 x 8 = 160,000 bits
Size in bytes = 160,000 / 8 = 20,000 bytes

You should also be comfortable working in the other direction: converting a given binary pattern into the picture it represents, reading it pixel by pixel and colour value by colour value, and the reverse, writing down the bit pattern that a given small bitmap represents.

Representing sound

Sound in the real world is analogue: a continuous wave of changing air pressure, like the smooth curve of a hill rather than a staircase. A computer cannot store a smooth curve directly, so it takes repeated snapshots of that wave, a process called sampling, and stores each snapshot as a number. Two things describe how faithfully this captures the original sound.

• Sampling rate is how many snapshots are taken every second, measured in hertz, where one hertz equals one sample per second. Take more snapshots per second and you capture the shape of the wave more accurately, in the same way a flick-book with more pages captures smoother motion.
• Sample resolution is how many bits are used to store each individual snapshot. More bits per sample means each snapshot can record a finer degree of detail in the sound's amplitude at that instant.

Worked example: calculating sound file size

File size in bits = sampling rate x sample resolution x number of seconds
Recording: 8,000 Hz, 16 bits per sample, 3 seconds
Size = 8,000 x 16 x 3 = 384,000 bits

Notice the pattern here is very similar to the bitmap calculation: multiply the quantity of samples or pixels by the amount of information stored per unit, and the result is the total size before any compression is applied.

Data compression

Once you can calculate how large uncompressed images and sound files really are, it becomes obvious why compression matters: raw files are big, and storage space and transmission bandwidth both cost something. Compression reduces the number of bits needed to store the same information, and this specification covers two different approaches: Huffman coding and run length encoding.

Huffman coding

Huffman coding gives shorter binary codes to characters that appear more often and longer codes to characters that appear less often, a bit like giving the most frequently used word in a shorthand system its own quick squiggle while rarer words get spelled out more fully. This works by building a Huffman tree from the frequency of each character, then reading the code for each character as the path taken from the root of the tree down to that character's position.

You should be able to build a Huffman tree from a given piece of data, interpret an existing Huffman tree to read off the code for a particular character, and calculate how many bits are needed to store data once compressed this way, comparing that against how many bits the same data would need stored in plain ASCII.

Run length encoding

Run length encoding, often shortened to RLE, is suited to data containing long runs of the same repeated value, similar to describing a striped scarf as five rows of red, then three rows of white, rather than describing every single row individually. Instead of storing every repeated value one after another, RLE stores a frequency and value pair: how many times a value repeats, followed by the value itself.

Original: 0000011100000011
RLE frequency/value pairs: 5 0, 3 1, 6 0, 2 1

You may be given a bitmap-style row of binary data and asked to produce its RLE frequency and value pairs directly, exactly as shown above, so practise turning a row of repeated 0s and 1s into that pair format until it becomes quick and automatic.

Common mistakes to avoid

• Forgetting to divide by eight when converting a calculated file size from bits into bytes.
• Mixing up sampling rate and sample resolution when describing a sound recording's quality.
• Reading a Huffman tree code backwards, from the character up to the root instead of from the root down to the character.
• Writing RLE pairs the wrong way round, putting the value before the frequency instead of the frequency before the value.
• Assuming Unicode and ASCII are entirely separate systems, rather than remembering Unicode reuses ASCII's codes up to 127.

Self-check questions

1. Given that capital A is coded as 65 in ASCII, work out the code for capital N.
2. Calculate the file size in bytes for a bitmap image 150 pixels wide, 80 pixels high, with a colour depth of 4 bits.
3. Calculate the file size in bits for a 2 second sound recording sampled at 4,000 Hz with an 8 bit sample resolution.
4. Write the run length encoding frequency and value pairs for the binary string 111000011111000.
5. Explain, using an everyday analogy of your own, why Huffman coding gives shorter codes to more frequent characters.

Every calculation in this guide follows the same handful of formulas, so once you have worked through the examples above a couple of times, most exam questions in this area become a matter of plugging the right numbers into a method you already know well. These oxfordaqa igcse computer science revision notes on data representation: character encoding to data compression are here for exactly that kind of repeated, confidence-building practice, and revisiting data representation: character encoding to data compression oxfordaqa igcse material regularly is the surest way to keep the formulas fresh in your memory.

Keep building from here

Pair this guide with the earlier one on number bases and binary arithmetic, since colour depth, sample resolution and character codes are all just binary numbers underneath, and everything from that companion guide applies here too. Treat this page as part of your ongoing igcse 9210 data representation: character encoding to data compression revision, work back through a fresh batch of oxfordaqa igcse computer science practice questions whenever a calculation starts to feel unfamiliar, and lean on these oxfordaqa igcse computer science notes until every formula here feels like second nature rather than something to look up. You have now had every idea in this section oxfordaqa igcse computer science explained through a real-world comparison, and that is genuinely the best way to make it stick.