Past Exam Questions

Isochronous transmission.

Justification:

• Audio and video are continuous media. Each unit must be played at a well-determined deadline.
• Conferencing is interactive, so large playout buffers are not acceptable.
• Isochronous delivery bounds both delay and jitter. Audio and video stay in step (lip sync) and play smoothly.
• Missing a deadline is barely visible for one video frame, but audible in audio. Bounded jitter protects the audio stream.

These transmission modes come from the QoS unit textbook, not from this year's slides. See L05 for deadlines, jitter and real-time requirements.

1. Metadata (EXIF) analysis. Read make, model, lens, serial number, date, time and GPS. They must match the student's DSLR and the claimed event. Principle: the camera writes EXIF at capture time. Caution: social media strips metadata, and metadata is easy to edit, so it is supporting evidence only.
2. PRNU source identification. Take a set of reference images with the student's DSLR under uniform lighting. Average them to get the camera's noise reference. Extract the noise residual of the viral image and correlate it with the reference. Principle: Photo Response Non-Uniformity is a sensor noise pattern from microscopic pixel sensitivity differences. It is unique to each sensor, like a fingerprint. A strong match shows the image came from that camera.
3. Error level analysis. Re-save at a known JPEG quality and subtract. Uniform error levels suggest one camera original. Patches with different error levels suggest editing or recompression.
4. Statistical checks. Histograms, JPEG DCT block statistics and colour channel correlation should look like a camera original, not a downloaded or recompressed copy.
5. Shadow analysis. Check the sun position for the claimed time and place against the shadows in the image.

Conclusion: the claim holds only if PRNU matches the DSLR and metadata and other checks are consistent. See L04.

JPEG has five stages: colour space conversion, chroma downsampling, DCT, quantisation, RLE plus Huffman coding. Size differences come from:

1. Quantisation table (quality factor). This is the main cause. A low quality setting scales the table up, so more DCT coefficients round to zero. More zeros mean longer zero runs and a smaller file. At normal viewing size the difference may not be visible because the eye is less sensitive to high frequencies.
2. Chroma downsampling. 4:2:0 (2 by 2 averaging, $[1 : 1/4 : 1/4]$) stores half the data of 4:4:4. The eye barely notices colour detail loss.
3. Entropy coding. Optimised Huffman tables give a smaller file than the default tables, with identical pixels.
4. Image content and noise. Fine texture or sensor noise leaves more non-zero high-frequency coefficients after quantisation, so the RLE and Huffman output is longer.
5. Resolution and metadata. A larger pixel count, or embedded EXIF and thumbnails, adds bytes without changing the look.

See L02.

Sampling rate (samples per second, $f_s$):

• Nyquist-Shannon: a band-limited signal is reconstructed correctly only if $f_s \ge 2 f_{max}$.
• Too low a rate causes aliasing: high frequencies fold back as false lower tones.
• Real low-pass (anti-aliasing) filters roll off gradually, so practical rates leave a guard band. 44.1 kHz gives Nyquist 22.05 kHz (guard band 2.05 kHz above 20 kHz); 48 kHz gives 4 kHz; 96 kHz gives 28 kHz.
• A higher sampling rate does not mean better audio once the audible band (20 Hz to 20 kHz) is covered. It only enlarges the file.

Bit depth (bits per sample, $n$):

• Gives $2^n$ quantisation levels: 16 bits give 65,536; 24 bits give 16,777,216.
• The quantisation step is $\Delta = R / 2^n$ and the error is at most $\Delta / 2$. More bits mean less quantisation noise and a larger dynamic range (about 6 dB per bit).
• Sampling is lossless; choosing the resolution is the lossy step.

File size:

Both parameters scale the size linearly. Production picks the lowest rate and depth that cover the content: 44.1 or 48 kHz at 16 or 24 bits. Labs Exp 12 and 13 showed aliasing at low rates and audible noise at 4 and 8 bits. See L03.

Step 1. Preserve the evidence. Work on a copy, record a hash of the original, document every tool and setting.

Step 2. Metadata analysis (EXIF, IPTC, XMP). Look for conflicting timestamps or GPS, missing or modified camera fields, and an editing program in the Software tag. Cross-check time and GPS with other sources.

Step 3. Error level analysis. Re-save at a known quality, subtract and normalise. Clue: pasted or cloned regions show a different error level from their surroundings. Caveat: rough surfaces and edges show high error naturally; ELA is weak on faces.

Step 4. Key point matching (SIFT or SURF). Detect key points, build descriptors and match them within the image. Clue: clusters of matches between two separate areas reveal copy-move forgery (for example, a duplicated wall hiding a structure).

Step 5. PRNU analysis. Compare the noise residual with the claimed camera's reference pattern. Clue: a region with no matching PRNU was pasted in (splicing) or synthesised.

Step 6. Statistical analysis. Histograms (gaps or comb patterns), mean and variance, JPEG DCT block inconsistency (double compression), colour channel correlation, Fourier or wavelet features. Clue: local disturbance of natural statistics.

Step 7. Shadow and lighting analysis. Shadow directions must agree with one light source; the sun position (for example from SunEarthTools) must match the claimed time and place.

Interpretation.

• No single test is proof. Look for agreement: an ELA hotspot, a PRNU gap and a shadow mismatch over the same region make a strong case.
• If all tests are consistent, report "no evidence of manipulation found", not "proven genuine".
• Record false-positive sources (texture, recompression, platform stripping) and report findings with confidence levels.

See L04.

Step 1. Frequencies: A = 4, C = 4, B = 3, D = 3 (total 14).

Step 2. Merge the two smallest: B + D = 6. List: 4 (A), 4 (C), 6.

Step 3. Merge A + C = 8. List: 6, 8.

Step 4. Merge 6 + 8 = 14 (root).

Step 5. Label left 0, right 1: B = 00, D = 01, A = 10, C = 11.

            14
         0/    \1
         6      8
       0/ \1  0/ \1
       B   D  A   C

Step 6. Encode C D A B C A D B B C A D A C:

11 01 10 00 11 10 01 00 00 11 10 01 10 11 = 28 bits.

Average: $28 / 14 = 2$ bits per symbol. The frequencies are almost equal, so Huffman cannot beat a 2-bit fixed code here.

Course convention: search buffer = window minus look-ahead $= 5 - 4 = 1$. Only the previous single symbol is searchable.

13 tokens for 14 symbols. The only match is the repeated B at step 9.

If the paper meant a search buffer of 5 (window 9): (0,0,C) (0,0,D) (0,0,A) (0,0,B) (4,1,A) (5,1,B) (5,3,D) (2,1,C), that is 8 tokens. Step 7 finds "BCA" 5 back. State your reading in the exam.

Original: $14 \times 8 = 112$ bits (ASCII).

• Huffman wins. Four symbols need only 2 bits each, against 8 for ASCII.
• LZ77 fails here: the sequence is short, has few long repeats and the search buffer is tiny. Every unmatched symbol costs a whole triplet.
• Against a 2-bit fixed-length code, Huffman's ratio is only 1 : 1, because the frequencies are nearly uniform.
• LZ77 pays off on long, repetitive data; Huffman pays off on skewed frequencies. PNG and DEFLATE use both.

See L01.

Application QoS requirements:

Range specification: a pair of values $[QoS_{min}, QoS_{max}]$, for example 15 to 30 fps. Below $QoS_{min}$ is the unacceptable region.

Specification approaches (from the slides), and the fit here:

• Parameter-based: QoS values (max latency, min bandwidth) stored in data structures. The app sets its limits.
• Script-based: a script lowers the bit rate when bandwidth drops. This is adaptive bit rate streaming.
• Control-based logic: adaptive policies for jitter and loss, such as a bigger buffer or retransmission.
• Object-oriented: each stream object carries bit rate, resolution and buffering time.
• Process-oriented and aspect-based approaches are less natural for a single mobile client.

The app uses scaling and adaptation rather than reservation. It cannot reserve resources on a mobile network, so it adapts quality in real time, as Netflix and YouTube do. See L05.

Step 1. Highest component: $f_{max} = 750$ Hz.

Step 2. Nyquist rate: $f_s \ge 2 \times 750 = 1500$ Hz. In practice choose a little more, for example 1600 Hz or more, so the filter has a guard band.

Step 3. Example below the limit, $f_s = 1000$ Hz: the Nyquist frequency is 500 Hz.

Step 4. 750 Hz aliases to $\lvert 750 - 1000 \rvert = 250$ Hz, a false tone that was not in the original.

Step 5. 500 Hz sits exactly at $f_s/2$. It may be sampled at its zero crossings and vanish, or its amplitude may be wrong.

Effect: the reconstructed audio contains wrong frequencies and distortion. The error cannot be removed after sampling because the alias is indistinguishable from a real tone. Prevention: an anti-aliasing low-pass filter before the ADC and $f_s \gt 2 f_{max}$. See L03.

Watermarking is viewed as communication: message, channel encoder, channel (the content), noise (editing, compression), channel decoder.

1. Basic model: cover work as noise.

m --> [Watermark encoder] --w--> (+) --> [Noise / attacks] --> [Detector] --> m'
                                  ^
                           cover work c0 (treated as noise)

The encoder ignores the cover content. It supports blind detection and robust extraction. Use: copyright and transaction tracking.

2. Watermarking with side information.

                 c0 ----------------+
                 |                  v
m --> [Encoder that knows c0] --> (+) --> [Noise] --> [Detector] --> m'

The encoder uses the original content. It embeds more strongly in dark or textured areas, where changes are hard to see, and more weakly in bright, flat areas. Better fidelity and robustness for the same strength.

3. Watermarking as multiplexed communication.

c0 (message for humans) --+
                          +--> [Embed] --> cw --> human sees c0, machine decodes m
m  (message for machines) +

The cover is a second message that must be preserved. This balances fidelity and robustness and may need informed detection. Use: authentication and quality-sensitive applications.

See L06.

Proposal: a medium GOP of about 1 second. For 30 fps: GOP 30 with pattern IBBPBBPBBP... (an I-frame every 30 frames, P every third frame, 2 B-frames between anchors). A shorter GOP of 12 to 15 (IBBPBBPBBPBBPBB) suits editing-style frequent seeking.

Justification:

• Compression: lecture video is mostly static (slides, a talking head). P- and B-frames code only small changes, so long runs of them save a lot of space. B-frames compress best.
• Seeking: decoding must start at an I-frame. With one every second, any seek lands within 1 s and needs at most 29 extra frames decoded. GOP 120 would mean up to 4 s of extra decoding per seek.
• Error resilience: a lost frame affects at most one GOP, so the picture recovers within a second.
• Smooth playback: B-frames need the next anchor, so a small decoder buffer of a few frames is enough at this GOP size.
• An extra I-frame at each slide change makes chapter jumps exact.

The slides list streaming (H.264) at 30 to 60 and editing at 12 to 15. A lecture platform needs both, so 15 to 30 is the balanced choice. See L03.

Cover work. Large, high-resolution, highly textured or noisy natural photos (landscapes, crowds, foliage) taken by the phone itself. Avoid flat or synthetic images (sky, screenshots), where any change shows. Use fresh photos never posted before, so no clean original exists for comparison. A complex image hides data better than a plain one.

Embedding method. Phone photos are JPEG, so embed in the DCT domain with a statistics-preserving method such as OutGuess:

• Phase 1: embed message bits in the LSBs of selected, less significant DCT coefficients. Leave some coefficients untouched.
• Phase 2: adjust the untouched coefficients so the DCT histogram matches the original.
• Alternatively, use model-based steganography: keep the probabilistic model $P(c_{emb} \mid c_{inv})$ of the cover unchanged.
• Encrypt and compress the text first, so the embedded bits look random.

Selection rule. Adaptive selection driven by a pseudo-random order from a shared stego key. Embed only in noisy, textured blocks. Never use sequential LSB from the top-left corner.

Limits: keep the payload small (OutGuess fails to preserve statistics when over-embedded), and send images in a way that does not recompress them, since platform recompression may destroy the data. See L06.

Practical notes:

• SIFT is more accurate; SURF is faster.
• PRNU needs reference images from the source camera.
• ELA gives false positives on rough surfaces and faces, so confirm with a second method.
• Inpainting from the same image's patches can also produce key point matches, so run SIFT on suspected object-removal areas too.

See L04.

Resource types.

Two phases.

1. Establishment (admission control): before a new stream starts, check that enough CPU, bandwidth and buffer remain without degrading streams already running. Reject or downgrade the request if not.
2. Runtime: monitor and reallocate. If an upload burst competes, throttle the upload, not the live class.

Service classes.

• Live class streams: guaranteed service with resource reservation. Use a deterministic pair of values such as 25 to 30 fps and a minimum bit rate.
• Recorded lectures: predictable service based on measured history (for example the average of the last L bandwidth samples).
• File uploads and maintenance: best effort. Run maintenance in off-peak hours.

Requirements to protect: throughput (bit rate per stream), delay (local and end-to-end), jitter (buffering, periodic scheduling) and reliability (error correction).

Delivery model: live classes use the push model (server sends to all clients). Recorded lectures use the pull model (client requests). Media servers rely on sequential access, large buffers and real-time scheduling, unlike a normal file server.

See L05.

1. GPS location (the strongest red flag). 34.0522 N, 118.2437 W is downtown Los Angeles, not San Francisco (about 37.77 N, 122.42 W, roughly 560 km away). Check: plot the coordinates on a map. Either the claim is false, the GPS was spoofed, or the metadata came from another photo.

2. Date and time consistency.

• 2023-07-22 was a Saturday, consistent with "weekend".
• Created 09:21:45 local; GPS 16:21:40 UTC. California in July is UTC-7 (PDT), so 16:21 UTC is 09:21 local. The clocks agree within 5 s. The file name IMG_20230722_092145 matches the creation time.
• Check: compare all time fields, time zone and file system times. Watch for time zone settings on the camera.

3. Editing software and modification time. Software: Lightroom Mobile 8.1 and a modification 2.5 minutes after capture show the file was edited, not straight from the camera. The DCI-P3 profile and the 1.8 MB size (small for a 12 MP phone JPEG) are consistent with re-export. Check: ELA and JPEG double-compression statistics; ask for the original from the phone's DCIM folder.

4. Device and camera parameters. 4032 x 3024 (12 MP), f/1.8 and 26 mm (35 mm equivalent) fit the S21 main camera. But "lens info 1.8-2.4 mm" looks like an aperture range written as a focal length, which is suspicious. Check: compare all EXIF fields with genuine S21 images, and run PRNU matching against reference shots from the user's own phone. That is the decisive device test.

5. Scene and environment (shadow analysis). 1/1200 s, ISO 40, flash off and HDR on mean bright sunlight around 09:21. Check: use SunEarthTools to compute the sun's azimuth and elevation for that time at both LA and SF, then compare with the shadow directions in the image. Also check landmarks and weather records for 22 July 2023.

Verdict: time fields are consistent. Location contradicts the claim and the file was edited, so the claim is not supported. Confirm with PRNU and shadow analysis before concluding. Metadata alone can be forged, so report it with the other evidence. See L04.

Start passive (no alert to the group), add active sanitisation for high-risk accounts, and move to malicious once the algorithm is identified.

Blind steganalysis, because the algorithm is unknown.

• Targeted steganalysis needs the embedding algorithm. For LSB embedding, for example, it uses the sum of absolute differences between neighbours as a feature. The agency does not know the algorithm, so it cannot pick such features.
• Blind steganalysis detects hidden data without knowing the algorithm. Two ways to train the classifier:
  • on stego images from many known algorithms (risk: misses a new algorithm);
  • on cover images only (one-class learning); anything far from the normal distribution is flagged.
• A universal blind classifier works across spatial and JPEG domains. That fits social-media images, which are recompressed JPEGs.
• Features: noise patterns, pixel correlation, transform-domain (DCT, Fourier) features.

Plan: blind steganalysis to screen, then targeted steganalysis on flagged images once the tool is suspected (for example a Steghide or OutGuess signature). See L06.

Rules: find the longest match of the look-ahead in the search buffer (it may overlap into the look-ahead). On a tie take the smallest offset. Output a pointer (offset, length) for a match, otherwise a literal. A pointer has no next-symbol field. The deck uses a pointer even for a one-character match; that rule is followed here.

Encoded output:

M I S (1,1) (3,4) P (1,1) (3,1) (11,6) (3,2)

Notes: at step 5, "ISS" starts 3 back and the copy continues with the newly copied I, giving "ISSI". At step 9 the match fills the whole look-ahead (6). At step 10 "SI" also occurs 11 back, but 3 is nearer.

19 characters rebuilt exactly, so the method is lossless. A flag bit (0 = literal, 1 = pointer) tells the decoder which kind each token is.

Step 1. Literals: M, I, S, P = 4. Pointers: (1,1), (3,4), (1,1), (3,1), (11,6), (3,2) = 6.

Step 2. Compressed size: $4 \times 1 + 6 \times 2 = 16$ bytes.

Step 3. Original: 19 bytes. Ratio: $19 / 16 = 1.19 : 1$. Saving: $(19 - 16)/19 = 15.8\%$.

Step 4. Improvement: a 2-byte pointer for a 1-character match wastes a byte. With a minimum match length of 2, steps 4, 7 and 8 become literals: M I S S (3,4) P P I (11,6) (3,2). That is 7 literals and 3 pointers: $7 + 6 = 13$ bytes, ratio $19/13 = 1.46 : 1$, saving 31.6%.

Comment: the string is short, so the gain is modest. The long repeat "MISSIS" (6 bytes into 2) does most of the work. Offsets up to 12 fit in 4 bits and lengths up to 6 in 3 bits, so a pointer fits in 2 bytes with room for the flag. See L01.

Convention: a missing neighbour (left of column 1, above row 1) is 0. All results are mod 256. Average uses $\lfloor (L + U)/2 \rfloor$.

None (unchanged): same as the input.

Sub ($X - L$):

Up ($X - U$):

Row 4 is below row 3, so the differences are negative: $20 - 22 = -2 \rightarrow 254$.

Average ($X - \lfloor (L+U)/2 \rfloor$):

Example: r2 c2: $L = 18$, $U = 19$, $\lfloor 37/2 \rfloor = 18$, $24 - 18 = 6$.

Paeth ($V = L + U - UL$, predict with the nearest of L, U, UL):

Worked Paeth cells:

Step 1. r2 c2: L = 18, U = 19, UL = 12. $V = 25$. Distances: 7, 6, 13. Predict U = 19: $24 - 19 = 5$.

Step 2. r4 c5: L = 40, U = 51, UL = 44. $V = 47$. Distances: 7, 4, 3. Predict UL = 44: $49 - 44 = 5$.

Step 3. r4 c4: L = 34, U = 44, UL = 36. $V = 42$. Distances: 8, 2, 6. Predict U = 44: $40 - 44 = -4 \rightarrow 252$.

Step 4. Row 1 has U = UL = 0, so Paeth picks L (same as Sub). Column 1 has L = UL = 0, so it picks U (same as Up).

Comparison: None keeps large, all-different values. Sub and Average give small residuals (1 to 9) in every row, with Average the smallest in row 4. Up and Paeth give small values in rows 2 and 3 but wrap to about 253 in row 4. The 254s still repeat, which DEFLATE can use. The gradient runs mostly horizontally (+6 to +8 per column), so Sub and Average suit this image best for the next stages (LZSS and Huffman). See L02.

Yes.

The step size is fixed, so a quiet passage spans only a few of the 256 levels. The error is then large relative to the signal and sounds like distortion. 12 bits gives 16 times finer steps and about 24 dB less noise. Cost: 50% more bits per sample. See L03.

Shutter speed. It sets how long the sensor is exposed to light. A faster shutter (for example 1/1000 s instead of 1/60 s) gives a shorter exposure time. The athlete moves less while the shutter is open and appears frozen. The slide: higher shutter speeds suit fast-moving objects and prevent motion blur.

Side effect: less light reaches the sensor, so the image is darker. Compensate with a wider aperture or a higher ISO. See L02.

Missing neighbours count as 0.

Working:

Step 1. Sub, row 1, fifth value: $(0 - 252) \bmod 256 = -252 + 256 = 4$.

Step 2. Up, row 2: $100 - 240 = -140 \rightarrow 116$; $106 - 244 = -138 \rightarrow 118$; ...; $124 - 0 = 124$; $130 - 4 = 126$.

Sub is better. Values rise steadily along each row (+4 and +6), so Sub leaves runs of identical small residuals. Even the wrap 252 to 0 becomes 4. Up leaves row 1 unchanged and gives all-different values in row 2, because the rows are not similar vertically. See L02.

Use MPEG-style coding, which removes spatial and temporal redundancy. Store a full reference frame, then code later frames as motion vectors plus small residuals per 16 x 16 macroblock (best match by SAD). The static background costs almost nothing; only blocks with the moving person need data.

Coding every frame independently (like JPEG on each frame) removes only spatial redundancy. The unchanged background would be re-encoded in every frame.

So the I-frame stands alone; P- and B-frames are relative (inter-frame). They are arranged in a GOP such as IBBPBBPBBPBB (12 frames).

Prefer System A. The system must support playback and access to recordings. Investigators need fast, exact jumps to the moment a person appears, and evidence should not lose long stretches to one damaged frame. P- and B-frames still remove most of the static background. Choose B only if storage is the single overriding limit. See L03.

1. Colour space conversion (RGB to YCbCr). Separates luminance Y from chrominance Cb, Cr. The eye is more sensitive to brightness, so colour can be treated more aggressively. Reversible; no data removed yet.
2. Chroma downsampling. Y stays at full resolution; Cb and Cr are averaged per 2 by 2 block, ratio $[1 : 1/4 : 1/4]$. Data falls from 3 to 1.5 values per pixel, a 50% cut with little visible change.
3. Block splitting, level shift, DCT. 8 by 8 blocks, subtract 128 (range -128 to 127), 2-D DCT to the frequency domain. Energy gathers in a few low-frequency coefficients (DC at top left). The DCT itself discards nothing.
4. Quantisation (the lossy step). Divide each coefficient by the quantisation table and round. Small table values at low frequencies, large at high frequencies, because the eye is less sensitive to fine detail. Most high-frequency coefficients become 0.
5. Entropy coding. Zigzag scan (low to high frequency) puts the zeros together; RLE codes the runs; Huffman gives short codes to frequent symbols. Lossless.

Together these routinely give 10 : 1 or more with good quality, so 40 MB to 4 MB is achievable. The slide shows exactly this example.

Quantisation. The quality setting scales the quantisation table (Lab Exp 5 used 0.5, 1 and 4 times the standard table).

• Larger table values (lower quality): more coefficients round to 0, longer zero runs, higher compression ratio, smaller file. Quality drops: blur, 8 by 8 blocking, ringing at edges. In the lab block, non-zero coefficients fell from 20 (x1) to 8 (x4).
• Smaller table values (higher quality): more coefficients survive, better reconstruction, lower ratio, bigger file (24 non-zero at x0.5).

Pick the highest quality that brings the file under 4 MB. See L02.

No. Nyquist requires $f_s \ge 2 f_{max} = 2 \times 18 = 36$ kHz. At 30 kHz the Nyquist frequency is $30/2 = 15$ kHz, so content from 15 to 18 kHz cannot be represented.

Aliasing.

Step 1. Components above $f_s/2 = 15$ kHz get fewer than two samples per cycle. The samples also fit a lower-frequency wave, so the wave shape is misread.

Step 2. An 18 kHz tone folds about 15 kHz: alias $= 30 - 18 = 12$ kHz. A 16 kHz tone appears at $30 - 16 = 14$ kHz.

Step 3. The aliases fall in the audible band and look like real content, so they cannot be removed after sampling.

Step 4. Minimum theoretical rate: $f_{s,min} = 2 \times 18 = 36$ kHz. The slides suggest strictly more than twice (1 Hz needs more than 2 samples per second).

The deck's extreme case: sampling 4 kHz at 8 kHz puts every sample at 0, so no wave is recovered.

• Real anti-aliasing filters are not ideal. They roll off gradually. At 44.1 kHz the Nyquist frequency is 22.05 kHz, leaving a guard band above the 18 to 20 kHz audio for the filter to cut.
• Safer reconstruction. More samples per cycle near the top of the band reduce misreading of the waveform and ease the DAC's reconstruction filter.
• Standard compatibility. 44.1 kHz, 16-bit PCM is the CD standard and covers the full hearing range to 20 kHz.

A higher rate is not automatically better audio; it only needs to stay safely above twice the highest frequency. See L03.

Key steps:

Step 1. Token 7: T was seen 6 back; the next character is a space, so (6, 1, ␣).

Step 2. Token 11: a space occurs 7 and 11 back; both give length 1; take the nearer, 7.

Step 3. Token 12: the search buffer holds exactly "HE␣CAT␣CHASES␣T". The look-ahead matches 14 characters from 15 back; the 15th character, T, is the next symbol.

Step 4. Token 14: only "HE␣CAT" remains: 5 characters match and T ends the message.

Check: $6 \times 1 + 5 \times 2 + 15 + 15 + 6 = 52$ characters. 14 tokens.

Step 1. Original: $52 \times 8 = 416$ bits.

Step 2. Token size: offset 0 to 15 needs 4 bits, length 0 to 14 needs 4 bits, symbol 8 bits: 16 bits per token.

Step 3. Encoded: $14 \times 16 = 224$ bits.

Step 4. Ratio $416 / 224 = 1.86 : 1$. Saving $(416 - 224)/416 = 46.2\%$.

Comment: effective overall, because the 15-character phrase repeats and each repeat costs one 16-bit token instead of 120 bits. The start expands: the first 11 tokens cover 16 characters but cost 176 bits against 128. LZ77 suits long repetitive data. LZSS would send the early characters as cheap literals. See L01.