Data Representation and Multimedia: Question 5

Worked solution

Part (a): Uncompressed sound file size

Three factors determine an uncompressed sound file’s size: sampling rate (samples per second), sampling resolution (bits per sample), and duration (seconds).

Total number of samples taken:

8000 samples/second x 5 seconds = 40,000 samples

Each sample uses 16 bits, so the total size in bits is:

40,000 x 16 = 640,000 bits

Converting bits to bytes (divide by 8):

640,000 / 8 = 80,000 bytes

[3 marks]: [1] for the total number of samples (40,000), [1] for multiplying by the sampling resolution to get the total in bits (640,000 bits), [1] for correctly converting to bytes (80,000 bytes).

Part (b): Lossy vs lossless compression

Difference: Lossy compression permanently removes some of the original data or detail to achieve a greater reduction in file size, so the file cannot be restored to be identical to the original. Lossless compression only removes redundancy in the data, so the original file can be reconstructed exactly, with no data lost.

Why lossless here: This recording may be used as legal evidence, so it must remain an exact, unaltered record of what was said. Lossy compression could permanently discard audio detail (and, depending on the method used, subtly change the sound), which could be challenged as having altered the evidence. Lossless compression guarantees the recording can be perfectly reconstructed, preserving its integrity as evidence.

[2 marks]: [1] for a correct difference between lossy and lossless compression, [1] for a correct justification linking lossless compression to preserving the recording unaltered for legal/evidential use.

Part (c): Run-length encoding the pixel row

First, identify each run (a consecutive sequence of the same value) in the 20-pixel row, and count how many pixels are in each run:

WWWWW BBB WWWWWWWW BBBB
  5W    3B    8W     4B

• 5 white pixels
• 3 black pixels
• 8 white pixels
• 4 black pixels

Check: 5 + 3 + 8 + 4 = 20 pixels, which matches the original row length.

RLE encoding. Instead of storing all 20 individual pixel values, store each run as a (value, count) pair:

(W,5) (B,3) (W,8) (B,4)

This needs only 4 pairs of data instead of 20 individual pixel values, which is why RLE compresses a row like this with long runs of the same colour.

Decoding back to the original. Expand each pair into that many repeated pixels, in order:

(W,5) -> WWWWW
(B,3) -> BBB
(W,8) -> WWWWWWWW
(B,4) -> BBBB

Concatenating these in order:

WWWWW + BBB + WWWWWWWW + BBBB = WWWWWBBBWWWWWWWWBBBB

This is exactly the original 20-pixel sequence, so the encoding is fully reversible (lossless).

[4 marks]: [1] for correctly identifying all four runs and their lengths, [1] for the correct RLE encoding (W,5)(B,3)(W,8)(B,4), [1] for correctly decoding each pair back into repeated pixels, [1] for showing the decoded sequence matches the original 20-pixel row exactly.

Final answers

• (a) 80,000 bytes
• (b) Lossless compression can be perfectly reconstructed (no data lost); lossy cannot. Lossless should be used here so the legal-evidence recording is not altered.
• (c) RLE encoding: (W,5)(B,3)(W,8)(B,4); decodes back to WWWWWBBBWWWWWWWWBBBB, matching the original exactly.