HookWhy the same song is 40 MB or 2 MB
Play a song on Spotify and it arrives at roughly 320 kilobits a second - about 2.4 MB for a four-minute track. Rip that same track straight off a CD, uncompressed, and it is closer to 40 MB. Nothing about the music changed; what changed is how cleverly the data was stored. The gap between those two numbers is very nearly the whole of section 1.2, because storage is the art of squeezing meaning - numbers, letters, colours, sound - into nothing but bits, and then getting it back out again without losing what matters.
OCR asks you to work along a chain. First, why a computer needs fast primary storage as well as roomy secondary storage, and how RAM differs from ROM. Then the units data is measured in, and the sums that size a file or a disk. Then the actual conversions - denary to binary to hexadecimal, and how characters, images and sound become binary in the first place. And finally compression: how you shrink all of it to fit on a card or fly down a network. Every one of these is testable as a calculation, so this is a section you learn by doing the arithmetic, not just reading about it.
ModelPrimary storage: RAM, ROM and the memory a computer pretends to have
Primary storage is the memory the CPU can read from and write to directly, and the computer needs it because secondary storage such as a hard drive is far too slow to feed the processor instruction by instruction. There are two kinds. RAM (random access memory) is the large, fast working memory that holds the operating system, the programs you have open and the data they are using right now. It is volatile - cut the power and its contents vanish - which is exactly why unsaved work is lost in a crash. ROM (read-only memory) is small and non-volatile: it keeps its contents with the power off, and it stores the bootstrap, the start-up instructions the computer runs the instant it is switched on, before the operating system has even loaded from disk.
When RAM fills up, the operating system borrows a slice of secondary storage and treats it as virtual memory: data that has not been used recently is moved out of RAM onto the drive to free space, then swapped back when it is needed again. It stops the machine running out of memory, but because the drive is so much slower than RAM, leaning on virtual memory heavily makes everything crawl - the constant disk activity you notice when far too many programs are open at once.
CaseSecondary storage: three technologies, five trade-offs
Secondary storage is where data and programs live permanently - when the power is off and when they are not in use - everything RAM cannot keep. It comes in three technologies. Magnetic storage, such as a traditional hard disk drive, stores bits as patterns of magnetism on spinning platters; it is cheap per gigabyte and high-capacity, but slower and mechanically fragile because it has moving parts. Optical storage - CDs, DVDs, Blu-ray - stores bits as pits read by a laser; it is cheap, portable and handy for distributing films or software, but low-capacity and easily scratched. Solid state storage, such as an SSD or a USB flash drive, stores bits in flash memory with no moving parts; it is fast, silent, shock-resistant and low-power, but more expensive per gigabyte.
Exam questions almost always ask you to choose a device for a scenario and justify it against the standard characteristics: capacity, speed, portability, durability, reliability and cost. The trick is to match the characteristic to the need in the question. A data centre backing up petabytes overnight cares most about cost per gigabyte, so magnetic drives win. A photographer working outdoors cares about speed and shock-resistance, so an SSD wins. A magazine giving away trial software cares about cheap mass duplication, so an optical disc wins.
DataUnits: bits, bytes and why OCR counts in thousands
Everything a computer stores is ultimately bits - binary digits, each a 0 or a 1 - because the hardware can only reliably tell two states apart. Bits are grouped: 4 bits make a nibble, 8 bits make a byte, and one byte is the smallest chunk normally used to store a single character. From there the units climb in thousands - 1,000 bytes are a kilobyte (kB), 1,000 kB a megabyte (MB), then a gigabyte (GB), terabyte (TB) and petabyte (PB), each a thousand times the last.
That word thousand is a deliberate OCR choice worth memorising: J277 defines a kilobyte as exactly 1,000 bytes, not 1,024. The 1,024 figure (two to the power of ten) is the older, strictly binary definition, and using it in a J277 capacity calculation will cost you the mark. Capacity questions are then just multiplication and careful unit conversion - work out the size of one item in bytes, multiply by how many there are, and convert up the ladder by dividing by 1,000 at each step. State the unit at every stage, because an answer of '8,000' with no unit is only half a mark.
How many 4 MB photos fit on a 32 GB memory card? First put both in the same unit: 32 GB = 32 x 1,000 = 32,000 MB. Then divide: 32,000 divided by 4 = 8,000 photos. Now the other direction. How large is a plain-text file of 2,000 characters if each character takes one byte? 2,000 bytes = 2,000 divided by 1,000 = 2 kB. Two moves each time - size of one item, then multiply or divide - and the only place students trip is forgetting OCR's 1,000-not-1,024 rule when they convert between units.
MechanismNumbers: binary, hexadecimal, addition and shifts
Because the machine only has bits, every denary (base-10) number has to be turned into binary (base-2). An 8-bit byte has place values 128, 64, 32, 16, 8, 4, 2, 1; to convert denary to binary you subtract the largest place value that fits, write a 1 there, and repeat with what is left. Hexadecimal (base-16) is shorthand for binary: one hex digit (0 to 9, then A to F for 10 to 15) represents exactly four bits, so a whole byte is two tidy hex digits. Programmers use hex because it is far easier to read and copy than a long row of ones and zeros - HTML colour codes and memory addresses are written in it.
You also need binary addition, working right to left and carrying a 1 whenever a column adds to two (which is 10 in binary) or three (11). If a carry falls off the left-hand end of the byte, the result is too big to fit in 8 bits: that is an overflow error, and the stored answer is wrong. Finally, a binary shift moves every bit left or right. A left shift of one place doubles the value (multiplies by 2); a right shift halves it; any bits pushed off the end are simply lost, which is how a right shift can quietly discard a remainder.
Denary to binary: 200 = 128 + 64 + 8, so 200 = 1100 1000. Binary to denary: 1011 0110 = 128 + 32 + 16 + 4 + 2 = 182. Denary to hex: 214 divided by 16 = 13 remainder 6; 13 is D, so 214 = D6 - and its binary 1101 0110 splits into the nibbles 1101 (D) and 0110 (6), matching perfectly. Binary addition: 0110 1101 (109) + 0101 1010 (90), added column by column with carries, gives 1100 0111 = 199, which fits in 8 bits, so no overflow. But 1000 0000 (128) + 1000 0000 (128) carries a 1 off the top into a 9th bit - the byte reads 0000 0000 and the true answer 256 is lost: that is overflow. Shift: 0000 1100 (12) shifted left two places becomes 0011 0000 (48), a multiply by 4.
MechanismCharacters, images and sound: same trick, bigger numbers
Text, pictures and audio are all stored as binary too; the only question is how the mapping works. Characters use a character set - an agreed table pairing each character with a number. ASCII uses 7 bits per character, so it can represent two to the power of seven, which is 128 characters, enough for the English letters, digits and punctuation. The rule to memorise is that relationship: n bits can represent two to the power of n different characters, so the larger Unicode set, using 16 bits or more, covers well over a million, which is how emoji and every world alphabet fit into one standard.
An image is a grid of pixels, each pixel's colour stored as a binary number. Two settings drive both quality and file size: resolution (how many pixels there are) and colour depth (the bits used per pixel, where a depth of n gives two to the power of n colours). Files also carry metadata - width, height, colour depth, date taken and so on - so the computer knows how to rebuild the picture. Sound is captured by sampling: measuring the height of the sound wave thousands of times a second. A higher sample rate (samples per second) and higher bit depth (bits per sample) give a more faithful recording and a bigger file, as does a longer duration.
Image file size in bits = width x height x colour depth. An 800 x 600 photo at 24-bit colour = 800 x 600 x 24 = 11,520,000 bits. Divide by 8 for bytes (1,440,000), then by 1,000 twice: 1.44 MB. Halve the colour depth to 12 bits and the file halves too. Sound file size in bits = sample rate x bit depth x duration. A 30-second mono clip at 44,100 Hz and 16-bit depth = 44,100 x 16 x 30 = 21,168,000 bits = 2,646,000 bytes = 2.65 MB. Record it in stereo (two channels) and it doubles. Each answer is one multiplication, then a divide by 8, then the unit conversion - write the formula down first and the marks follow.
ModelCompression: throw bits away, or pack them tighter
Those file sizes are exactly why compression exists - to shrink files so they take less storage and travel faster over a network, the difference between a photo loading instantly and a page that stalls. There are two families. Lossy compression permanently throws away the data a human is least likely to miss: MP3 discards frequencies you can barely hear, JPEG merges subtly different colours. The file gets dramatically smaller, but the discarded detail is gone forever and you can never rebuild the original exactly. Lossless compression stores the same data more efficiently without losing anything, so the original is reconstructed perfectly - essential for text, spreadsheets, program code or a ZIP archive, where a single changed character would be a disaster. The trade-off is blunt: lossy gives smaller files but lower fidelity; lossless preserves everything but saves less.
One easy-to-follow lossless method is run-length encoding, which replaces a long run of the same value with a single value and a count. It is brilliant for simple graphics with big blocks of one colour and useless for a noisy photograph where almost nothing repeats.
Run-length encoding of the pixel row W W W W W W B B B W W W records it as 6W 3B 3W - twelve values stored as six, and the original row rebuilds exactly, so nothing is lost. But feed it a row where no two neighbours match, such as W B W B W B, and it stores 1W 1B 1W 1B 1W 1B: twelve values become twelve pairs and the 'compressed' file is actually bigger. That is the lesson examiners test - lossless compression only helps when the data genuinely contains repetition.
VocabularyKey terms the mark scheme pays for
TrapsMisconceptions that cost marks
ExamWhat examiners want
This section is marked on method, so show your working. In a binary or hex conversion, write the place values (128, 64, 32...) above the digits: even if the final number is wrong, a correct method usually earns a mark, and a bare answer with no working earns nothing if it is wrong. For file-size questions, always write the formula first - width x height x colour depth for images, sample rate x bit depth x duration for sound - then substitute, then convert, carrying the unit at every line. Divide by 8 to turn bits into bytes and by 1,000 to climb the units, using OCR's 1,000, never 1,024.
Be exact with vocabulary the mark scheme pays for. Say RAM is volatile and ROM is non-volatile; say lossy compression permanently removes data while lossless can be fully restored. On a 'choose the storage device and justify it' question - a common 6-mark levelled item - name the device, then link it to the specific need in the scenario using the six characteristics (capacity, speed, portability, durability, reliability, cost), and weigh at least one trade-off. Generic answers that describe an SSD without tying it to the scenario stay in the bottom band.