drwily/Dragon-s-Lair-X68k
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Take the climb to a real branch point, and find the cadence has a third column

Browse Source 
FINDINGS 70, and it closes ROADMAP P6.  65.6 recorded that "the slack table is
here, but 51.3's refill climb with a second consumer through a real branch point
is not", and 67.6 repeated it verbatim two sessions later.
tools/analysis/36_branch_audio.py is that run: 51.3's surplus model, 56.3's 612
real branch points, 32's cadence arithmetic, both containers' headers and the
buffer constants of the player 68 measured, in one place.  No machine -- all
five were already numbers.

AUDIO IS 1.7% OF THE CODEC WIRE AND UP TO 3.30x OF THE CLIMB.  Slack accrues out
of pipe - wire, which is a small difference of two large numbers, so a second
consumer is not priced by its share of the wire -- which is how every budget in
this tree since FINDINGS 8 has quoted it.  At 451.4 KB/s (the container's own
zero-prefill pipe, 49.5) in a 256 KB ring the climb goes 6.70 s -> 22.11 s and
the branch points arriving under it go 482/612 (79%) -> 603/612 (99%).  At 488
it is 1.19x, at 600 it is 1.05x.  Correction to 56.4: it charged audio at
ratectl.AUDIO_KBPS = 7.8, which is 7,812.5 B/s in decimal kB; in binary KB the
figure is 7.6294, so the placeholder was 2.24% high and every column moved in
the flattering direction by less than one part in six hundred of the wire.

AND ON THE PACKED BRANCH THERE IS NO CLIMB AT ALL.  A record goes straight into
GVRAM, so the video lookahead is zero records and 56.4's alarming column is
vacuous when every frame arrives with less lookahead than the one before it.
Acceptance there is a per-frame deadline, not an average, which is why B1 has to
name a burst rate.  The only consumer on that branch with any lookahead is the
audio one: 1.833 s of sound held against 0.000 s of picture.  And at 589.6 KB/s
-- the acceptance figure this project quotes -- the sounded container's surplus
is exactly zero: it plays and never banks a byte, while the silent one climbs
its record in 6.38 s.

THE COST NOBODY HAD COUNTED.  A DLXP2 group is `lump k, then F records`, so lump
k is at a LOWER address than every record of its group but the first, and a seek
to record i finds its audio behind it.  Measured on the 409 within-container
seek targets of the arcade's own graph at the shipped F=11: mean 416.5 ms of
silence entering a branch, median 416.7, p90 750.0, worst 833.3, and only 36 of
409 land on a group boundary.  The other 203 -- the scene changes -- are free by
construction, because lump 0 sits between the header and record 0.  The
container's own start is the one branch point the cadence costs nothing at, and
it was the only one anybody had looked at.

SO THE CADENCE PICK IS REOPENED, on a third column.  32_audio_wire chose F=11 on
padding and RAM; F=1, the cadence it called the worst one, has no group to enter
off-boundary at all, and gives back 12,288 B of RAM for +4.36 KB/s of wire
(0.74% of the acceptance figure).  The alternative is a second read: lump k is
up to 503,808 B behind, so it is a separate command of 7,168 B -- 11.7 ms
against 416, 36x cheaper in time -- and src/player/packed.s starts PG_AK/PG_AKF
at lump 0 and has no audio seek path at all.  Nothing here decides it; the
deciding number is what one more SCSI command costs, and that is B1's.  The
content is not uniform mod F either: the measured mean runs 0.67x..1.23x of a
uniform assumption across the sweep, and the 1.00x at F=11 is a coincidence.

New check.sh stage, ~10 s, and it gates the STRUCTURE and deliberately not the
milliseconds: audio never shortens a climb, the shipped cadence strands most
within-container branches, F=1 strands none, and the lump read is an order of
magnitude cheaper than the silence it removes.

The one thing 70.3 and 70.4 rest on is a DESIGN ASSUMPTION and is printed in the
tool's own output: one container per SCENE (53, 55.1, 56.3).  One container per
sequence makes every seek land on frame 0 and empties both sections.

No encoder, player or container byte moved.

Claude-Session: https://claude.ai/code/session_01194oWYW8DQXK1SZ2DnChW6
This commit is contained in:
prosolis
2026-08-25 14:21:32 -07:00
parent ab15c0749a
commit 8b5f51704c
6 changed files with 817 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/FINDINGS.md
+180
View File
@@ -7529,3 +7529,183 @@ and was aimed one layer too late.
sees, which is the right unit for a clamp question and the wrong one for a
mixing question.
* **Nothing was listened to.** Unchanged since 68.6.
---
# Findings — session 38 (2026-08-25)
## 70. The refill climb meets a branch point with sound on the wire — and the cadence turns out to have a third column (session 38)
ROADMAP P6, the last item in it and the oldest: 65.6 recorded that "the slack
table is here, but 51.3's refill climb with a second consumer through a real
branch point is not", and 67.6 repeated it word for word two sessions later.
`tools/analysis/36_branch_audio.py` is that run. It puts five things that have
never been in the same room together — 51.3's surplus model, 56.3's 612 real
branch points, 32's cadence arithmetic, the two containers, and the buffer
constants of the player 68 measured — and it needs no machine, because every
one of them is already a number.
python3 tools/analysis/36_branch_audio.py --kbps 451.4 488.0 513.2 600.0 \
--ring 256 512 # ~10 s
python3 tools/analysis/36_branch_audio.py --gate # the check.sh stage
### 70.1 THE HEADLINE, on the codec branch: audio is 1.7% of the wire and up to 3.30x of the climb
Slack is accumulated out of `pipe - wire` (51.3), and `pipe - wire` is a small
difference of two large numbers. A second consumer is therefore **not** priced
by its share of the wire, which is how every budget in this tree from FINDINGS 8
onward has quoted it. Gate container, the game's own 612 gaps:
| ring KB | pipe | ceiling | climb SILENT | SOUNDED | ×| under, silent | under, sounded |
|---:|---:|---:|---:|---:|---:|---:|---:|
| 256 | 451.4 | 2 | 6.70 s | **22.11 s** | **3.30** | 482/612 (79%) | **603/612 (99%)** |
| 256 | 488.0 | 7 | 5.40 s | 6.44 s | 1.19 | 451/612 | 475/612 |
| 256 | 513.2 | 7 | 3.53 s | 3.95 s | 1.12 | 351/612 | 372/612 |
| 256 | 600.0 | 7 | 1.61 s | 1.69 s | 1.05 | 129/612 | 130/612 |
| 512 | 488.0 | 10 | 7.72 s | 9.19 s | 1.19 | 514/612 | 542/612 |
| 512 | 513.2 | 14 | 7.06 s | 7.89 s | 1.12 | 497/612 | 520/612 |
| 512 | 600.0 | 14 | 3.22 s | 3.38 s | 1.05 | 298/612 | 303/612 |
**7.63 KB/s of sound triples the climb at 451.4 and pushes the branch points
that arrive under it from 79% to 99% of the game.** Nothing about the audio got
bigger between those two columns; the quantity it is subtracted from got
smaller. 451.4 is not a corner case — it is the container's own zero-prefill
pipe (49.5), the rate at which the *silent* container is exactly deliverable.
**The rate at which a container is deliverable and the rate at which it can
absorb a branch were already different (51.4); with a second consumer the gap
between them is a factor of three.**
A **correction to 56.4**, and it is small enough to be worth stating precisely
so it is not mistaken for a bigger one: that table charged audio at
`ratectl.AUDIO_KBPS = 7.8`, which is 7,812.5 B/s written in decimal kB. In the
binary KB every other column uses it is **7.6294**, i.e. the placeholder was
**2.24% high** — 0.04% of the wire. Every 56.4 column moves in the flattering
direction by less than one part in six hundred. A placeholder that turns out to
be right is still a placeholder.
### 70.2 On the packed branch there is no climb at all, and that is the finding
The packed player puts a record **straight into GVRAM** (61, 62, 64.2): the
transfer *is* the paint, so there is no record buffer and the **video lookahead
is zero records**. 51.3's question has no answer there, because there is no
accumulator for play to fill.
* **56.4's alarming column does not apply to the DMAC-direct packed player** —
"most branch points arrive with less lookahead than the one before them" is
vacuous when *every frame* does.
* Its acceptance is a **per-frame deadline**: 49,664 B inside every slot. A pipe
that averages 589.6 KB/s over a second is a different claim, and that is why
B1's acceptance has to name the data-phase burst rate as well as the sustained
one (64.2).
* **The only consumer on that branch with any lookahead is the audio one**:
7,168 B a lump, three slots and a prefill of two as run (68.6), which is
**1.833 s of sound held against 0.000 s of picture.** The stream this project
spent four sessions adding is the better-buffered of the two.
For the CPU-painted variant (64.2 column B, 99,328 B, two record buffers, one
record of lookahead):
| pipe | climb SILENT | SOUNDED | × | under, silent | under, sounded |
|---:|---:|---:|---:|---:|---:|
| **589.6** | 6.38 s | **never** | ∞ | 473/612 | **612/612** |
| 600.0 | 2.69 s | 4.68 s | 1.74 | 263/612 | 421/612 |
| 650.0 | 0.71 s | 0.80 s | 1.13 | 43/612 | 49/612 |
| 700.0 | 0.41 s | 0.44 s | 1.07 | 33/612 | 33/612 |
**Read the first row.** 589.6 KB/s is the acceptance figure this project quotes
for the packed branch, and it is precisely the rate at which the sounded
container's surplus is **zero** — it plays, and it never accumulates a byte of
lookahead at any amount of play. The silent container at that same rate climbs
its one record in 6.38 s. **"Deliverable" and "able to survive a branch" are the
same rate only for a container with no second consumer in it.**
### 70.3 The cost nobody had counted: entering a group off-boundary
A DLXP2 group is `lump k, then F records` (dlxp.py), so **lump k lies at a lower
address than every record of its group except the first**. Read forward from
record *i* and the next lump to arrive is *k+1*, which carries frame *(k+1)F* —
so the frames from *i* to *(k+1)F−1* have picture and no sound. The missing
time is exactly `(F − i mod F) mod F` frames of **1/12 s**, and it is an exact
1/12 s: the chip's second is 15,625 samples and none of FINDINGS 54's
frame-clock remainder gets into it.
Measured on the **409 within-container seek targets of the arcade's own graph**,
at the shipped cadence F=11:
| | |
|---|---:|
| mean silence entering the branch | **416.5 ms** |
| median / p90 / worst | 416.7 / 750.0 / **833.3 ms** |
| land on a group boundary and cost nothing | **36 of 409** |
The other **203 branch points — the scene changes — are free, and by
construction**: lump 0 sits at sector 1 and record 0 at 7,680, so a container's
first bytes are header, lump, record and a scene change reads them in one
forward pass. **The container's own start is the one branch point the cadence
costs nothing at, and it is the only one anybody had ever looked at.**
**The fix is a second read, and no player in this tree has one.** Lump *k* is up
to 503,808 B behind record *i*, so it cannot be picked up by reading early — it
is a separate command at a separate LBA, of 7,168 B, which at 600 KB/s is
**11.7 ms against a mean 416 ms of silence, 36x cheaper in time**. It costs one
more command per branch and **the command overhead is B1's and unmeasured**.
`src/player/packed.s` starts `PG_AK`/`PG_AKF` at lump 0 and has no audio seek
path at all.
### 70.4 So the cadence pick is reopened, on a column it did not have
32_audio_wire.py chose F=11 on two columns, padding and RAM. Here is the third,
measured on the game's own seek targets:
| F | A | lump B | padding | audio KB/s | RAM ×2 | mean sil | worst | free |
|---:|---:|---:|---:|---:|---:|---:|---:|---:|
| **1** | 2 | 1,024 | 57.29% | 12.000 | **2,048** | **0.0** | **0.0** | **409/409** |
| 3 | 4 | 2,048 | 4.86% | 8.000 | 4,096 | 102.5 | 166.7 | 93/409 |
| 7 | 9 | 4,608 | 1.11% | 7.714 | 9,216 | 209.5 | 500.0 | 78/409 |
| **11** | 14 | 7,168 | **0.09%** | **7.636** | 14,336 | 416.5 | 833.3 | 36/409 |
| 12 | 16 | 8,192 | 4.86% | 8.000 | 16,384 | 519.4 | 916.7 | 34/409 |
**F=1 — the cadence 32_audio_wire called the worst one — has no group to enter
off-boundary at all**: no second read, no audio seek path, no silence at any
branch point, and 2,048 B of held lump instead of 14,336. It costs **+4.36 KB/s
of wire, 0.74% of the packed acceptance figure**, and it **gives back 12,288 B
of RAM** on the branch whose entire argument is that RAM is the resource it has
spare (64.2).
**This is a trade and not an error.** Padding is what F=11 minimises and padding
is not the only thing F sets. A player that gets its audio seek right is
indifferent between them; a player that does not pays a mean 416 ms of silence
at 409 of the game's 612 branch points. **Nothing here decides it — the
deciding number is the SCSI command overhead of the extra read, and that is
B1's.** F=7 is the middle if one is wanted: 1.11% padding, +0.08 KB/s over
F=11, 9,216 B held, and half the silence.
**And the content is not uniform mod F.** A uniform assumption puts the mean at
(F−1)/2 frames; the arcade's seek targets land where they land, and the measured
mean runs **0.67x to 1.23x** of uniform across the sweep — a design that assumed
uniform would be a quarter out at F=3. At the shipped F=11 the ratio is
**1.00x**, which is a coincidence and is reported as one.
### 70.5 What this does NOT establish
1. **No rate here is measured.** Every pipe column is a sensitivity (FINDINGS
50). **B1 — sustained *and* data-phase burst — is still the user's**, and
70.2's first row is a reminder that the two are not interchangeable.
2. **The frame index of a seek target is a DESIGN ASSUMPTION**, and it is the
one thing 70.3 and 70.4 rest on. DLXSCENE1 carries laserdisc-timeline
positions in ms; this design puts **one container per scene** (53, 55.1, and
56.3's 203 container changes), so the index is
`(target start − the scene's earliest start) × fps / 1000`. **One container
per *sequence* makes every seek land on frame 0, the group offset always
zero, and 70.3/70.4 empty.** Nothing else in the file changes.
3. **Nothing ran on a machine.** This is arithmetic over a scene table, two
containers and a player's own constants. **68's player has never seeked**,
and the audio seek path 70.3 asks for does not exist to be measured.
4. **The mechanical seek is still unmodelled** (51.7.5) and is charged on top of
every millisecond above.
5. **The silence is a container property, not a chip one.** What an MSM6258V
does when it is not fed — hold the last sample, or click — is a board
question and belongs with session 34's fifth hardware item.
6. **The 409/203 split is the graph's, not a container manifest's.** No scene
has been encoded but one; the mapping from a scene to a DLXP2 is a design
statement this tree has made and not yet built.
docs/ROADMAP.md
+33 -4
View File
@@ -172,6 +172,28 @@ through a real branch point** — and 69.4 adds two small unbuilt cases, a scene
with no audio track (`00176`) and a scene whose audio is shorter than its video
(`00199`).
Amended end of session 38: **P6 IS CLOSED, AND THE LAST ITEM IN IT REOPENED THE
CADENCE (FINDINGS 70).** `tools/analysis/36_branch_audio.py` runs 51.3's climb
against 56.3's 612 real branch points with the second consumer on the wire. On
the codec branch **audio is 1.7% of the wire and up to 3.30x of the climb** —
6.70 s → 22.11 s at 451.4 KB/s, and 79% → 99% of the game's branch points
arriving under it — because slack accrues out of `pipe − wire` and that is a
small difference of two large numbers. On the packed branch **there is no climb
at all**: a record goes straight into GVRAM, video lookahead is zero records,
and the only consumer with any lookahead is the audio one (1.833 s of sound
against 0.000 s of picture). **At 589.6 KB/s — the acceptance figure — the
sounded packed container's surplus is exactly zero**, which is the sharpest
statement yet of why B1 must name a burst rate and not only a sustained one.
And a cost nobody had counted: a DLXP2 group is `lump k, then F records`, so a
seek into a group finds its audio BEHIND it — **mean 416.5 ms of silence at the
409 within-container branch points, worst 833.3 ms, 36 of 409 free**, while all
203 scene changes are free by construction. **The fix is one extra read of
7,168 B (11.7 ms against 416) and no player has an audio seek path**; the
alternative is F=1, which gives back 12,288 B of RAM for +4.36 KB/s of wire.
**The cadence pick is therefore reopened and the deciding number is B1's**: what
one extra SCSI command costs. **What is left of P6 is nothing** — 69.4's two
unbuilt cases and 70.3's seek path are player work, not open questions.
**THE COMPLETION TARGET IS M3, THE VERTICAL SLICE** (USER DECISION): one scene
tree — a decision point, two outcomes, a death clip — with audio, streaming from
a real SCSI volume on a stock 2 MB machine, playable. That is the point at which
@@ -736,8 +758,10 @@ playing from disc on stock hardware.**
**P6. Audio. P6a DONE, session 34 — FINDINGS 66.** ~~and it is the largest
unpriced risk left in the project.~~ Three quarters of P6 closed in session 33
and the fourth precondition — which decoder the chip runs — closed in 34, on the
machine, through the real DMA channel. **What is left of P6 is P6b (DLXP2, a
container with sound in it) and the refill climb with a second consumer.**
machine, through the real DMA channel. ~~**What is left of P6 is P6b (DLXP2, a
container with sound in it) and the refill climb with a second consumer.**~~
**P6 IS CLOSED end of session 38** — P6b in 35, P6c in 36, the level in 37 and
the refill climb with a second consumer in 38 (FINDINGS 70).
*(original framing, kept because every figure below is still the live one:)*
MSM6258 ADPCM, 15.6 kHz mono, **7.8 KB/s**. That figure is in `ratectl.py`'s
@@ -780,10 +804,15 @@ container's cadence is `F=11, A=14`** — 0.09% padding, 14,336 B held, 582.0
57.3% of every audio sector. **The codec container pays zero padding**, because
it already has the index the packed one deleted (65.4).
**What is left in P6 is the fourth: the refill climb with a second consumer
~~**What is left in P6 is the fourth: the refill climb with a second consumer
through a real branch point** (51.3, 55.4). The slack table is in
`32_audio_wire.py` — at 582.0 KB/s exactly, silent breaks even and sounded
starves — but a branch point has not been run with audio on the wire.
starves — but a branch point has not been run with audio on the wire.~~
**DONE, session 38 — FINDINGS 70**, and it produced three things the slack table
could not: the climb multiplier (up to **3.30x** for **1.7%** of the wire), the
fact that the packed branch has **no accumulator to climb**, and the group-entry
silence (**mean 416.5 ms** at 409 of the game's 612 branch points) that reopens
the cadence pick on a third column. `tools/analysis/36_branch_audio.py`.
**P6a. WHICH DELTA FORMULA DOES THE MSM6258 RUN? (new, session 33, FINDINGS
65.2 — and it is a precondition, not a refinement.)** ffmpeg computes
docs/STATUS.md
+103
View File
@@ -1,3 +1,106 @@
# Status & next-session handoff — end of session 38 (2026-08-25)
## Session 38: the climb meets a branch point with sound on it, and the cadence has a third column
**FINDINGS 70.** ROADMAP P6's last and oldest item, named by 65.6 and repeated
verbatim by 67.6: 51.3's refill climb with a second consumer, through a real
branch point. `tools/analysis/36_branch_audio.py` puts five things that had
never been in the same room together — 51.3's surplus model, 56.3's 612 real
branch points, 32's cadence arithmetic, both containers, and the buffer
constants of the player 68 measured. It needs no machine: all five were already
numbers.
**THE HEADLINE. Audio is 1.7% of the codec wire and up to 3.30x of the climb.**
Slack accrues out of `pipe − wire`, which is a small difference of two large
numbers, so a second consumer is *not* priced by its share of the wire — which
is how every budget in this tree since FINDINGS 8 has quoted it. At 451.4 KB/s
(the container's own zero-prefill pipe, 49.5) in a 256 KB ring the climb goes
**6.70 s → 22.11 s** and the branch points arriving under it go **482/612 (79%)
→ 603/612 (99%)**. At 488 it is 1.19x, at 600 it is 1.05x.
**AND ON THE PACKED BRANCH THERE IS NO CLIMB AT ALL.** The packed player puts a
record straight into GVRAM, so its **video lookahead is zero records** and
51.3's question has no answer there: 56.4's alarming column is vacuous when
every frame arrives with less lookahead than the one before it. Its acceptance
is a per-frame deadline, not an average, which is why B1 has to name a burst
rate. **The only consumer on that branch with any lookahead is the audio one** —
1.833 s of sound held against 0.000 s of picture. And on the CPU-painted variant
the acceptance figure itself reads differently: **at 589.6 KB/s the sounded
container's surplus is exactly zero**, so it plays and never accumulates a byte,
while the silent one climbs its record in 6.38 s.
**THE COST NOBODY HAD COUNTED.** A DLXP2 group is `lump k, then F records`, so
lump *k* is at a LOWER address than every record of its group but the first. A
seek to record *i* finds its audio behind it and the next lump ahead carries
frame *(k+1)F*. Measured on the **409 within-container seek targets of the
arcade's own graph** at the shipped F=11: **mean 416.5 ms of silence entering a
branch, worst 833.3 ms, and only 36 of 409 land on a group boundary.** The other
203 — the scene changes — are free by construction, because lump 0 sits between
the header and record 0. **The container's own start is the one branch point the
cadence costs nothing at, and it is the only one anybody had looked at.**
**SO THE CADENCE PICK IS REOPENED**, on a third column. F=1 — the cadence
32_audio_wire called the worst one — has no group to enter off-boundary, and it
gives back **12,288 B of RAM** for **+4.36 KB/s of wire (0.74%)**. The
alternative is a second read: lump *k* is up to 503,808 B behind, so it is a
separate command of 7,168 B — **11.7 ms against 416 ms, 36x cheaper in time** —
and `src/player/packed.s` has no audio seek path at all. **Nothing here decides
it; the deciding number is the extra command's overhead, and that is B1's.**
**What changed in the tree.** One new analysis file and one new ~10 s check.sh
stage that gates the STRUCTURE and deliberately not the milliseconds: audio
never shortens a climb, the shipped cadence strands most within-container
branches, F=1 strands none, and the lump read is an order of magnitude cheaper
than the silence it removes. No encoder, player or container byte moved.
## HANDOFF — start here
**THE TREE IS ALL GREEN**, session 38's stage included.
### The work, in the order it should be done
**1. THE AUDIO SEEK PATH (70.3), and it is now the cheapest thing that moves
something.** `PG_AK`/`PG_AKF` start at lump 0 and there is no way to enter a
group off-boundary. One extra read at `PG_ALBA0 + k*(F*PG_RECS + PG_CADA)` plus
a byte offset inside the lump is the whole of it, and until it exists the player
cannot branch with sound. It also turns 70.4's reopened cadence question back
into a non-question.
**2. THE BUFFERING DEPTH, which is still cheap.** Unchanged from session 37's
handoff: `PG_ANBUF` is 3 and `PG_APRE` is a mailbox. Two slots is one constant
and one run. 70.2 adds a reason to care — the audio buffer is the packed
branch's *only* buffer.
**3. THE SILENT-CLIP AND SHORT-AUDIO CASES (69.4).** Unchanged: a scene whose
audio is shorter than its frames (`00199`), and a scene with no audio track at
all (`00176`). Both are decided by what the lump count is computed from.
### What is still BLOCKED, so it is not picked up by mistake
**K4 — the packed player that is on screen — is conditional on B2**, a board
question. **E7, E4 and C1** are parked (61.8), and **P4a's wiring** is parked
with the ring K3 deleted.
**The hardware list is unchanged and is the user's**: B1 (sustained AND the
data-phase BURST rate, 64.2 — acceptance is **589.6 KB/s**, and 70.2 is the
sharpest statement yet of why the two rates are not interchangeable), B2
(blanking), B3 (`#EXREQ`), B4 (a byte write to a palette register), and session
34's fifth, play a known nibble stream on a real MSM6258V and record the line
out. **Session 38 adds a sixth question to B1 and it is small**: what one extra
SCSI command costs, because that is the number 70.4's cadence trade turns on.
### Reproducing this session
python3 tools/analysis/36_branch_audio.py --kbps 451.4 488.0 513.2 600.0 \
--ring 256 512 # ~10 s, the essay
python3 tools/analysis/36_branch_audio.py --gate # the check.sh stage
./tools/bench/check.sh # ALL GREEN
**WHAT IS NEXT.** The audio seek path, which is the first thing in this project
that the content has asked for rather than the hardware.
---
# Status & next-session handoff — end of session 37 (2026-08-25)
## Session 37: the audio level is measured off the whole disc, and the headroom is not worth buying