Sylpheed/docs/re/structures/slb-data-offset.md

.slb leading-stream data offset — 1392 was never a constant

⚠️ Read the last section first. A second pass on 2026-08-26 closed the ❔ at the bottom of the original writeup: the offset is (cumulative start of the .pNN segment holding the wave) mod 2048, exact for 8 783 of 8 783 banks. The first_riff % 2048 rule below is a consequence of that and stays correct where a RIFF exists; the packet-plausibility scan and the seek-residue heuristic are superseded, and the 🟡 "most banks declare more data than they store" finding is withdrawn. Jump to X is the .pNN segment's grid phase.

✅ Settled 2026-08-26, verified by decoding. A bank's leading headerless packet stream does not start at a fixed offset. It starts at first_riff % 2048. HEADERLESS_DATA_OFFSET = 1392 is the value that offset happens to take in <lang>\etc\, and assuming it everywhere starts the decode mid-packet and throws away almost all of the audio.

The rule

XMA1 packets are 2048 bytes and the leading stream is a whole number of them ending at the first RIFF. So its start is forced:

start = first_riff % 2048

Disc-wide that lands on exactly four values — 1392, 1468, 1600, 1728 — all of the form 1392 + 4k. Across the 3 965 Japanese and 3 393 English banks with a non-empty leading region, no other value occurs:

	1392	1468	1600	1728
eng\etc, eng\Movie, eng\Briefing	1 520	—	—	—
eng\Voice	8	1 873	—	—
jpn\etc	—	1 402	303	—
jpn\Briefing	—	71	—	—
jpn\Movie	—	—	61	—
jpn\Voice	—	—	2 033	95

It varies by language and subdirectory, which is why a constant derived from eng\etc\ looked right for years' worth of the banks anyone had reason to open.

Verified by decoding, not by arithmetic

The alignment argument alone proves nothing — any offset can be made to "align" by definition. The test is whether more audio comes out. Decoded through FFmpeg's xma1 at mono/48 kHz, on a random sample of 140 banks that have a non-empty leading region:

outcome	banks
more audio at ri % 2048	85
byte-identical	54
less audio	1

Median gain among the improved: 70×. The 54 identical ones are the control — they are the eng\etc-style banks where ri % 2048 is 1392, so the rule must and does reproduce the old behaviour exactly. Individual cases:

eng\Voice\VOICE_TCAF_592.slb    1 506 ->  97 152 bytes   (65x)
jpn\Voice\VOICE_TCAF_592.slb    2 910 -> 127 178 bytes   (44x)
eng\etc\VOICE_D_452.slb        30 154 ->  30 154 bytes   (unchanged, control)

The one counterexample — ✅ explained

eng\Voice\VOICE_TCAF_608.slb decodes 2 840 bytes at 1392 and 896 at 1468.

It is not a bank where the old constant works and the derived offset fails: both offsets yield well under a tenth of a second from a 38 988-byte region, i.e. both fail, and 1392 merely produces marginally more garbage.

The reason is that the bank is truncated. Its data chunk declares 759 808 bytes and the pak entry holds 8 864 — 99 % short. There is almost nothing there to decode at any offset. See the section below.

❌ This withdraws my own claim from earlier the same day

sound-pak-contents.md reported that the leading region rule holds for "0 of 5 100 Japanese banks" and filed a backlog item saying the Japanese banks were a different, undecoded layout. That was wrong. The Japanese banks are the same format; only the offset differs. The measurement behind it was correct — zero of them satisfy (riff − 1392) % 2048 == 0 — but the conclusion drawn from it was not, and the reason is instructive: I treated HEADERLESS_DATA_OFFSET as a property of the format when it was a property of the sample the format was derived from.

The same error was hiding a defect in the English set too: 1 873 eng\Voice banks sit at 1468 and were being decoded mid-packet just as badly.

The RIFF-less banks had the same bug, plus a worse one

✅ Settled 2026-08-26. 1 495 banks (799 jpn, 696 eng) carry no RIFF at all and take a separate code path. That path was wrong twice over:

1. it used the constant offset, with no RIFF to derive from; and
2. it built a stereo fmt chunk.

Decoded across a random 48-bank sample:

banks where the old stereo-at-1392 beat the best mono offset	0 of 48
median gain	184×
range	25× – 489 344×

Stereo is the same failure signature recorded for the leading segment: it stops after one frame. Individual banks went from 0–4 816 bytes to 180 000–380 000.

The winning offsets fall out by directory, and they reproduce the distribution measured independently from the RIFF-bearing banks — which is the cross-check that makes this more than curve-fitting:

eng\etc 1392 (11/11)   eng\Voice 1468 (9/9)   eng\Briefing 1392 (2/2)
jpn\Voice 1600 (12/13) jpn\etc 1468 (8/12), 1600 (4)

Note jpn\etc splits, so the path alone is not enough to pick the offset.

Picking the offset without a decoder

An XMA1 packet opens with a big-endian header — 6 bits frame count, 15 bits frame-offset-in-bits, 3 bits metadata, 8 bits packet-skip. At the true offset those fields stay in range packet after packet; one byte off and they do not. Scoring the first 24 packets and taking the best candidate:

7 330 of 7 358 (99.62 %) on the labelled set — every bank that has a RIFF, where the answer is forced and therefore known. All 28 misses are ties on the top score; there is not a single case where the scan picks wrongly with a unique winner. scan_data_offset therefore falls back to 1392 on a tie.

This is used only for the RIFF-less banks. Where a RIFF exists the offset is derived from it exactly, never scanned.

✅ A second, independent signal — and it breaks the ties

Settled 2026-08-26. The 28 ties needed a different signal, not more of the same one, and the banks carry one: a seek chunk sitting on a packet boundary. Its position modulo 2048 therefore is the data offset.

seek at 3 516 / 5 564 / 7 612 / 9 660 / 13 756 / 19 900  —  all ≡ 1468 (mod 2048)

On the 6 033 labelled banks that have a seek before their first RIFF, 6 031 agree (99.97 %) and 2 disagree. That is better than the packet scan and, more importantly, structural rather than statistical — which is why it is now tried first.

Applied to the packet scan's 28 ties: 26 resolved correctly, 0 wrongly, and 2 with no usable seek. The combined rule — seek residue, else packet plausibility, else 1392 — scores 7 354 / 7 358 = 99.95 % on the labelled set, up from 99.62 %.

762 of the 1 495 RIFF-less banks carry a seek, and its residue lands on the four known offsets there too (1468 ×343, 1600 ×255, 1392 ×148, 1728 ×16), so the signal is available in the population that needs it.

❌ The header is not audio being discarded

Worth ruling out, since a wrong data offset was the whole subject of this page: if the bytes before the offset were audio, we would be throwing away the start of every clip. Adding 0 to the candidate set and re-running the scan, it wins 6 of 7 358 — noise. The header is genuinely not part of the packet stream. (1 482 banks have an all-zero header; 5 876 have content in it, which is what prompted the check.)

Is that 99.62 % transferable? — checked, and it is conservative

The labelled set has a RIFF; the population the scan actually serves does not. Since the scan is unbounded it reads past the RIFF on labelled banks, so the 99.62 % could have been borrowing discriminating power that a RIFF-less bank cannot offer. That would make the headline number optimistic for the only case it is used in — worth checking before trusting it.

Confining the scan to the leading region drops it to 69.98 % with 1 910 ties, which at first looks like exactly that problem. It is not. Splitting by how much leading audio there is separates the two explanations:

	correct	ties
unbounded, all 7 358 labelled banks	99.62 %	28
confined to the leading region, all 7 358	69.98 %	1 910
≥24 packets of leading audio (989 banks), unbounded	100 %	0
≥24 packets of leading audio (989 banks), confined	100 %	0

The last two rows settle it. Where there is enough audio to score, the discriminator is perfect whether or not the RIFF is in range — so it is not leaning on the RIFF. The 69.98 % is an artifact of short leading regions: with only two or three packets to judge, candidates tie and the tie-break decides. Unboundedness helps those banks by giving the scan more bytes, which is why the two columns differ at all.

A RIFF-less bank is a whole pak entry, tens of kilobytes, so 24 packets are always available — it is always in the 100 % regime. The 99.62 % figure is therefore conservative for the population the scan is used on, not optimistic.

What this does not settle

• ❔ Why the offset takes those four values, and what the bytes before it are. This was probed and remains open; what is now ruled out is recorded below.

• The 28 ties. The scan cannot separate them and falls back to 1392, which is right for roughly a third of that population and wrong for the rest.

• Why the offset takes exactly these four values by directory is still unexplained — see above.

• Nothing here was run in the game — this is a decoder-side result measured with FFmpeg as the oracle.

🟡 Most banks declare more data than they store

Measured 2026-08-26. Of the 7 586 banks that carry both a RIFF and a data chunk after it, 5 296 (69.8 %) declare a data size larger than the bytes actually present in the pak entry. The remaining 2 290 declare less, which is the ordinary multi-sub-wave case. Not one declares exactly what it holds.

Worst cases run to 99 % short:

eng\Movie\VOICE_RT16C.slb    declared 1 810 432   available 489 392   -73 %
jpn\etc\VOICE_D_589.slb      declared 1 177 600   available   6 708   -99 %
eng\Voice\VOICE_TCAF_608.slb declared   759 808   available   8 864   -99 %

This contradicts a claim in the decoder's own comment, which says the declared size "is honest per sub-wave". It is not, for about seven banks in ten. The code is nonetheless safe — it clamps the range with .min(slb.len()) — so this is a documentation defect and an integrity observation, not a crash.

⚠️ Method note on this measurement. My first pass searched for data from offset 0, which can hit those four bytes by chance inside the leading audio region and read a garbage length. Re-running it anchored after the first RIFF changed the count from 5 038 to 5 296 — the flaw was slightly under-counting, but it could as easily have gone the other way, and an unanchored chunk search over binary audio is not a safe way to ask this question.

❔ Why the declared sizes are too large is not settled. Plausible readings — an authoring-time allocation that was never trimmed, or deliberate truncation of unused tails — are guesses; nothing here distinguishes them, and the game has not been observed reading one of these banks.

❔ What the header is — four things it is not

The bytes before the data offset are still unexplained, but the field has been narrowed. Probing the header of banks at each of the four offsets:

• Not a length field. There is no word in the first 64 bytes equal to the offset, the offset minus 1392, the RIFF position or the entry size, in either endianness. The offset has to be derived; it is not read.
• Not a seek table or any ascending index. Treated as big-endian words, only about half of consecutive pairs are non-decreasing — which is what random data gives. Every word is distinct and none is zero, across all four offsets.
• Not zero padding, at least not usually: 1 482 of 7 358 banks have an all-zero header, but 5 876 have content in it.
• Not audio being discarded. Adding 0 to the offset candidates, it wins 6 of 7 358 — noise. (Recorded above.)

So it is high-entropy content of a size that is constant per language and subdirectory, carrying no field that names its own length. That combination suggests something the loader knows the size of a priori rather than something self-describing.

First step if this is picked up again: find the loader. SETTINGS.PATH is game:\dat\sound.pak+ and SETTINGS.PARAM is Pj_Silph.xgs, so there is code that opens a bank by name and seeks to its data; the constant, or the table it indexes, should be visible there. That is static PE work (/work/*.pe, offset = VA − 0x82000000), not another pass over the archive — this page has taken the byte-level evidence about as far as it goes.

---

✅ SETTLED 2026-08-26 (second pass) — X is the .pNN segment's grid phase

The open ❔ above ("why the offset takes those four values, and what is in those bytes") is now closed, exactly, with no residual heuristic:

X = (cumulative start of the .pNN segment file that holds the wave) mod 2048.

segment      size         size % 2048   cum_start      X
sound.p00    267 930 992      1392                0       0
sound.p01    268 404 812        76       267 930 992    1392
sound.p02    268 404 868       132       536 335 804    1468
sound.p03    268 384 384       128       804 740 672    1600
sound.p04     14 903 296         0     1 073 125 056    1728

The four values are the running sums of the segment sizes mod 2048. 1392 = |p00| mod 2048; 1468 = 1392 + 76; 1600 = 1468 + 132; 1728 = 1600 + 128. That identity is not a fit — it is arithmetic, and it comes out of five file sizes that nothing in this analysis chose.

Reproduce with tools/re-capture/slb_segment_phase.py phases.

Why

The XMA1 packet grid is 2048-aligned inside each individual .pNN file: a segment file starts at its own offset 0 with a bank header and everything after is on that file's own 2048 grid. But the .pak TOC addresses entries in the flat concatenation of p00..p04, and every TOC offset is itself a multiple of 2048 (checked: 0 of 9 519 entries are misaligned). The segment files are not multiples of 2048 long, so each join shifts the grid by size % 2048, and an entry inside segment k sees the accumulated shift.

Nothing in the game computes 1392. It is a build-time artifact of where the packer chose to cut a ~1.07 GB stream into five ~256 MB files.

Verification — 100 %, no exceptions

tools/re-capture/slb_segment_phase.py verify:

	banks	agree	disagree
has a RIFF/WAVE — X read off the wave header	7 620	7 620	0
RIFF-less — X read off the leading seek chunk	1 163	1 163	0

This replaces both heuristics in the section above. The packet-plausibility scan (99.62 %) and the seek-residue rule (99.97 %, combined 99.95 %) are no longer needed for anything: the offset is now derivable for every bank, including the 1 495 RIFF-less ones and including the 28 ties the scan could not break. Those sections stand as an honest record of how the number was narrowed, not as the recommended method.

The prediction that could have refuted it, and did not

If X really is a per-segment property rather than a per-bank one, then an entry that straddles a segment boundary must show two different phases inside one file. Exactly 3 of 9 518 entries straddle, and they do:

eng\Voice\VOICE_ACRO_010.slb   window starts 11 708 B before the p01→p02 join
    seek chunk @11 632   ≡ 1392 (mod 2048)      <- p01 phase
    ---- sound.p01 / sound.p02 join at 11 708 ----
    RIFF      @21 948   ≡ 1468 (mod 2048)      <- p02 phase
    seek      @52 668   ≡ 1468 (mod 2048)

jpn\etc\VOICE_D_149.slb  (1468 -> 1600)   jpn\Voice\VOICE_TCAF_577.slb  (1600 -> 1728)

A single-offset-per-bank model cannot produce that. ⚠️ It also means "the data offset of a bank" is not well defined for those three entries — any decoder that stores one offset per file will decode part of them mid-packet.

✅ What is in those X bytes: audio, from the previous bank

Not a header. They are the tail of the preceding bank's XMA1 packet stream, carried into this window because the TOC window boundary and the bank boundary are different things.

Three independent lines:

1. Statistics are identical to known audio. Over 167 eng\etc banks, the number of distinct byte values seen at each fixed offset averages 101.06 across [0, 1392) and 101.90 across [1392, 3440) — a region that is certainly one XMA packet. Not one position in [0, 3600) takes ≤8 distinct values, i.e. there is no fixed field anywhere in the header. A real header would show constants.

2. The tiling arithmetic is exact. A wave's seek (XMA dpds) chunk sits immediately after its data and holds one u32 LE per packet, so it names its own packet count and therefore where its data started. Entry K's last wave overruns the entry; entry K+1 opens with a seek whose packet count matches, at exactly the overrun distance measured past the TOC window rounded up to 2048:

    VOICE_D_451  window 67 704 -> padded 69 632   last wave ends at 73 072
    VOICE_D_452  leading seek @ 3 440 (14 packets)     73 072 - 69 632 = 3 440   ✅
    VOICE_D_452  window 67 704 -> padded 69 632   last wave ends at 103 792
    VOICE_D_453  leading seek @34 160 (20 packets)    103 792 - 69 632 = 34 160  ✅
   

   tools/re-capture/slb_segment_phase.py chain 'eng\etc\VOICE_D_450.slb' 4.

3. The bytes the TOC skips are audio too. Between the end of VOICE_D_451's stored 67 704 bytes and the start of VOICE_D_452 sit 1 928 bytes of .pNN that no entry claims. 1 903 of the 1 928 are non-zero — dense audio, not padding. The stream is continuous through them.

❌ Withdrawn: "the header is unique per bank, so it is not shared data"

An earlier step here searched all 1 088 MB of p00..p04 for one bank's exact 1 392-byte header and found one occurrence, its own — and I briefly read that as ruling out any shared-stream model. It does not. The windows tile, they do not overlap: the bytes appear once because they are stored once. The measurement was right, the inference from it was wrong.

✅ The real .slb bank layout (this is what the entries contain)

Each bank is self-contained and starts on its segment's 2048 grid. All fields big-endian.

+0x00  u32  bank / cue id           (BGM_001 -> 1001, BGM_105 -> 1105; voice ids run
                                     consecutively in stream order, e.g. 7228, 7229, …)
+0x04  u32  0x11 (17)               constant on every bank seen
+0x08  u32  0x20 (32)               constant
+0x0C  u32  1                       constant
+0x10  u32  0x48 (72)               constant
+0x14  u32  0
+0x18  u32  0x800                   BLOCK SIZE — the 2048 alignment unit
+0x1C  u32  data size in bytes      ❔ does not equal the sum of the waves; see below
+0x20  u32  bank id again
+0x24  u32  header size in BLOCKS   always 5 -> the first wave is at +10240
+0x28  u16  bits per sample (16)  u16  channels (2 for BGM, 4 for voice banks)
+0x2C  f32  } three floats, 1.0 / 0.5 / 0.1 on BGM_001, 1.0 / 0.4 on BGM_105
+0x30  f32  } ❔ volume / mix, not identified
+0x34  f32  }
...   zero fill to 0x2800 (10240)

then, repeated per wave:

RIFF/WAVE                            exactly 4096 bytes = 2 blocks:
  'fmt ' 32 bytes                    standard little-endian XMAWAVEFORMAT
  'Dmmy' 4028 bytes of zero          pad, so that…
  'data' <size>                      …audio begins at riff+4096, on the grid
<data>                               size is EXACTLY packets * 2048
'seek' 8 + 4*packets                 u32 LE cumulative decoded-sample counts

+0x18 == 0x800 plus bank[0x00] == bank[0x20] is a reliable signature: scanned at the correct phase it finds every bank and nothing else.

+0x24 is always 5 on this disc, so a bank's own audio starts 10 240 bytes after its header — but that header is generally not at offset 0 of the pak entry (see the next section), which is why the value never showed up as a constant.

The fmt chunk decodes cleanly as XMA1 XMAWAVEFORMAT

eng\etc\VOICE_D_452.slb first wave: tag 0x0165, 16 bits, NumStreams 1, LoopCount 0, Version 2, PsuedoBytesPerSec 12 212, SampleRate 48 000, loop 0..0, Channels 1, ChannelMask 1 — mono. BGM_105.slb: LoopCount 0xFF, PsuedoBytesPerSec 35 879, 48 000 Hz, LoopStart 0x003D72B1, LoopEnd 0x0168BDBA, Channels 2. So the format was never in doubt; only the framing was.

❌ Withdrawn: "🟡 Most banks declare more data than they store"

The section above reports that 5 296 of 7 586 banks (69.8 %) declare a data size larger than the entry holds, and calls the decoder's "honest per sub-wave" comment a documentation defect. The measurement was right and the reading was wrong — and the comment it accused was correct.

Declared data sizes are exact. The bytes are simply outside the TOC window, still present in the .pNN stream. Taking 400 random eng\/jpn\ banks and, for every last wave that overruns its window, reading the declared range straight from the segment stream: the wave's seek chunk lands at exactly the declared end in 260 of 260 cases, 0 failures.

So eng\Voice\VOICE_TCAF_608.slb is not "truncated, 99 % short", and that is not why it decodes badly — its wave continues into the next window. The counterexample section above needs revisiting on that basis.

data size is always an exact multiple of 2048, which is the packet count.

❔ Still open — the TOC window is not the bank

The .pak TOC entry for a cue is a window that contains the cue's bank but is not aligned to it, and the offset drifts entry to entry:

eng\etc\VOICE_D_450.slb   bank ids 7212 @ 7 536, 7226 @ 60 784
eng\etc\VOICE_D_451.slb   bank id  7228 @ 30 064
eng\etc\VOICE_D_452.slb   bank ids 7229 @  5 488, 7230 @ 48 496
eng\etc\VOICE_D_453.slb   bank id  7231 @ 36 208
eng\etc\VOICE_D_454.slb   bank id  7232 @ 50 544

Bank ids run consecutively in pak-offset order, so a name→bank mapping exists, but which bank in a window belongs to the entry's name is not established — some windows hold two. A window can also cut a bank in half. Since a bank header can only sit at ≡ X (mod 2048) while a TOC offset is ≡ 0, a bank header can never be at entry offset 0; the leading region is structural, not accidental.

❔ +0x1C (data size) does not match the sum of the wave data chunks — VOICE_D_452's bank 7229 declares 38 980 for a 26 624-byte wave. Unexplained.

🟡 The loader — found, mapped, and it does not contain X (null result)

Static search of default.xex (/work/*.pe, /work/xenia-rs/sylpheed.db), done as the deliberate refutation attempt: if some code computes X, it should be visible. It is not, and under the segment-phase explanation it should not be.

What was searched, all negative:

• 1392 / 1468 / 1600 / 1728 as immediates (li/addi/subi/cmpwi/ cmplwi/ori/lis, and the negations) over all 25 481 functions: 15 / 1 / 7 / 10 hits, every one accounted for and none audio-related. Only two functions hold ≥2 of the values and both are subi rN,r1,K / addi r1,rN,K stack-frame pairs (sub_82766DB0, sub_821DB270, both D3D/shader-compiler code). The most promising-looking hit — cmplwi cr6,r31,0x570 at 0x8217FC68, next door to the sound manager — is ERROR_FILE_CORRUPT, in a run of 0x7B/0x5/0xB7/0x48F = ERROR_INVALID_NAME/ACCESS_DENIED/ ALREADY_EXISTS/DEVICE_NOT_CONNECTED: storage-device retry code, not sizes. li r7,1468 at 0x827D3BC4 is a __LINE__ for an HLSL-compiler assert.
• A table of the four values anywhere in the 9 568 256-byte image: 32-bit BE aligned and unaligned, 32-bit LE, 16-bit both endians, and float32. Zero clusters holding ≥2 of the four. The only 4-byte-aligned BE occurrence of any of them in the whole image is one 1600 at 0x820489A0, in a zlib-adjacent globals blob. 0x8202D668 looks like a hit (… 0570 05BC …) but is a compiler message-offset table — it continues 0x664, 0x6B8, not 0x640, 0x6C0 — and is immediately followed by "internal error: unknown ".
• .slb / slb / XACT / XWB / xma / wavebank as strings — absent from the image in ASCII and UTF-16. No 4CC-shaped immediates in the audio code.

The sound subsystem, for whoever picks this up next (all located by residual __FILE__/debug-printf strings — the image has no user symbols at all: 25 310 of 25 481 functions are sub_XXXXXXXX, RTTI stripped, demangled_names empty):

range / address	what
0x82175E00–0x8217DC00	silph::SoundManager game layer
0x821774A0	BGM bank-slot manager — holds both the BankSlots::get_bgm_data_area (0x820A18B0) and BankSlots::setup_bgm (0x820A1938) failure strings
0x82179988	SoundManager::Impl::SetMovieMode, called from the movie handler 0x821B4968
0x82178F60	sound config loader — refs SOUNDS/SETTINGS/game:\ at 0x820A1878
0x82604A00–0x8260E900	gsfw sound_framework middleware, 383 functions; public entries 0x826069E8 (play/register, r3=15), 0x82606A38 (stop/release), 0x826062D8, 0x82605028; assert sites 0x82608120, 0x8260DF28, 0x8260D8C0, 0x8260D9D0 → the gsfw_object.h / gsfw_objectcore.cpp strings
0x824D1000–0x824DC400	XMA/XAudio driver — the only kernel audio imports (XMACreateContext wrapper 0x824D3BA8, XAudioRegisterRenderDriverClient 0x824DC280, …)

The one size-related constant on the bank path is in sub_821774A0: a 128 KB (0x20000) threshold on the loaded resource size, then addi r4,r29,2047 / addi r11,r3,2047 / clrrwi r11,r11,11 — allocate size + 2047 and round the pointer up to 2048 — stored at +76 of the slot struct and handed to a gsfw vtable slot. So the runtime does honour the 2048 grid; it just never needs to name 1392, because the 2048-alignment it applies is to its own buffer, and the phase is baked into the file at pack time.

🟡 rather than ✅ because the walk from "a bank is opened" to "the first packet is submitted" was not completed — sub_821774A0 is the BGM path, and no code was traced that consumes a voice .slb. The claim proven here is the narrower one: none of the four values exists as a constant or a table anywhere in the executable. That is consistent with, but does not by itself prove, "the game never needs X".

Consequences for our decoder

crates/sylpheed-formats/src/slb.rs currently takes the offset from first_riff % 2048 (right, where a RIFF exists) and from scan_data_offset otherwise (99.6 % right). Both can be replaced by the exact rule, which needs one new input: the pak offset of the entry, plus the segment start table — PakArchive already knows both. Suggested shape:

• PakArchive exposes segment_phase(concat_offset) -> usize.
• slb::to_xma_riff takes the phase instead of deriving it.
• the 3 straddling entries need the phase looked up per wave, not per file.

⚠️ Also worth revisiting: because the declared data sizes are honest and the window is not the bank, the reader currently clamps away audio that is really there. Reading a cue's full audio means reading past the TOC entry into the .pNN stream.

Not implemented here — this pass was static RE only, and the API change reaches every caller.

Evidence log

• 2026-08-26 — X = segment_cum_start % 2048. CONFIRMED. 7 620/7 620 banks with a RIFF and 1 163/1 163 RIFF-less banks via seek, 0 mismatches; independently, the four values are the running sums of the five .pNN sizes mod 2048; independently, the 3 straddling entries show the phase step inside one file at the segment join. tools/re-capture/slb_segment_phase.py.
• 2026-08-26 — leading X bytes are the previous bank's audio. CONFIRMED. Byte-diversity identical to a known packet (101.06 vs 101.90, no fixed field); seek packet counts chain exactly across three consecutive entries; the unclaimed inter-entry .pNN bytes are 1 903/1 928 non-zero.
• 2026-08-26 — declared data sizes are exact, 260/260 checked. Demotes the 🟡 "most banks declare more than they store" reading above.
• 2026-08-26 — no .slb data offset exists in default.xex. PROBABLE (exhaustive constant/table/string search; the loader walk itself is unfinished).