roadmap: band+0x80c (Q) full trace, band-mode switch table, coefficient generators, constants
This commit is contained in:
+32
@@ -305,3 +305,35 @@
|
|||||||
(1935б, 582 стр), `r_*/f_*/p_*` для всех ядер, `sizes.json`.
|
(1935б, 582 стр), `r_*/f_*/p_*` для всех ядер, `sizes.json`.
|
||||||
- **Следующий шаг**: транскрипция обоих близнецов в dsp/detect.cpp (или dsp/detector.cpp)
|
- **Следующий шаг**: транскрипция обоих близнецов в dsp/detect.cpp (или dsp/detector.cpp)
|
||||||
с точным порядком float/double операций + комплексного умножения rbp; верификация SNR 19.8 дБ.
|
с точным порядком float/double операций + комплексного умножения rbp; верификация SNR 19.8 дБ.
|
||||||
|
|
||||||
|
### B.7 — Коэффициенты детектора/внутренние моды band (2026-08-18) — ДЕШИФРОВАНО
|
||||||
|
- **Ghidra-путь Layer2**: `analyzeHeadless ... -process soothe_mem.bin -noanalysis -scriptPath D -postScript X.java`
|
||||||
|
(~60-90 с/запуск), `-noanalysis` ОК; image_base=0, но block `ram`=[0x180000000,0x186f48fff] =>
|
||||||
|
адреса = RVA; `A(v)=v` (не минус base). Старые `.py` не работают (нет PyGhidra) → только `.java`.
|
||||||
|
Побочный баг: скрипты в одной папке перестают компилироваться после одной правки (OSGi кэш по пути) —
|
||||||
|
обход: новый каталог на скрипт. Материалы: `/tmp/opencode/ghidra_out/*.java`+`qmode.txt/q2.txt/q3.txt/
|
||||||
|
consts.txt/swtab.txt/scanaddr.txt`, копии в `/tmp/det/ghidra/`.
|
||||||
|
- **band-структура (подтверждена сеттерами)**: `+0x800`=int mode (сеттер 0x18052d206: пишет XML value),
|
||||||
|
`+0x804`=freq float (0x18053763b), `+0x808`=sens float, `+0x80c`=**Q float** (0x180537615),
|
||||||
|
`+0x814`=order count (2/3/5), `+0x818/+0x820`=ptr, `+0x819/+0x81a`=byte флаги.
|
||||||
|
- **Писатель коэффициентов `FUN_1805316e0` (0x1805316e0..0x180532f3d)**: switch на `[band+0x800]`,
|
||||||
|
jump-table 0x180532f80 (база LEA 0x180000000, 17 случаев 0..16, >0x10→JA default), каждый case:
|
||||||
|
order в `+0x814`, вызов генератора, memcpy A/B→band.A/B (0x181132884, len `[+0x10]<<3`).
|
||||||
|
case1 (XML mode=1)=`FUN_1805343e0(fs,freq,Q=0.707)` — **фиксированный Q**, `+0x80c` НЕ читается!
|
||||||
|
case8 (default)=`FUN_180533ec0(fs,freq,Q=[+0x80c],10^(sens/20))` — полноценный RBJ bell, Q из поля.
|
||||||
|
Случаи 0/2/3/4/9..16 — другие типы (shelf/notch с константами 0.54/0.51/0.6/1.31/2.56...).
|
||||||
|
- **q-фактор из `+0x80c` на старте** (0x180531771..17f1): `2q²; (2q²+1)/2q²; ·2; ²·0.25−1;
|
||||||
|
(cf4); +XMM6; (cd0); ·100000; (cc4 on 2.0); /100000` → участвует в клипинге частоты и fVar16.
|
||||||
|
- **Генераторы (decomp3.txt)**: `FUN_1805343e0` w=1/FUN_181a14cfa((freq·π)/fs), k=(1/Q)·w,
|
||||||
|
a=1/(k+1+w²), A=[a,2a,a], B=[1,(1−w²)·2a,(1−k+w²)·a]; `FUN_180533ec0` RBJ bell с gain
|
||||||
|
(f=(float)p5, w0=clamp·2π/fs, alpha=(cos·0.5)/Q, a0=alpha·f+1, b0=alpha/f+1, b1=s·−0.5);
|
||||||
|
FUN_180534300 (3rd-order вариант), FUN_180533ff0/180534180 (1-3 order bell/notch).
|
||||||
|
- **Константы (consts.txt)**: (float) 0x1824c41e0=2.0, 0x1824c3ea4=1.0, 0x1824c3d3c=0.25,
|
||||||
|
0x1824c45f8=100000.0, 0x1824c3e00=0.707, 0x1824c3d8c=0.5; (double) 0x1824c43d0=100000.0,
|
||||||
|
0x1824c40c0=0.707, 0x1824c4698=−0.5, 0x1824c4f20=−0.0, 0x1824c4270=10.0, 0x1824c42b0=20.0.
|
||||||
|
- **Матем. хелперы 0x181a14xxx — IAT-стабы** (`JMP [0x181bab3xx]`), цели 0x6fffff... вне дампа
|
||||||
|
(грузит плагин). Семантика `FUN_181a14cfa` не подтверждена: кандидаты sin/sqrt/tan —
|
||||||
|
проверяется на харнессе против baseline (corr 0.99475/SNR 19.80/diff −0.065).
|
||||||
|
- **ОТКРЫТЫЙ ВОПРОС**: какой case фактически исполняется для band1 при XML mode=1
|
||||||
|
(case1: Q=0.707 фикс vs case8: Q из +0x80c + gain) — нужен замер. Вопрос (c): factory default
|
||||||
|
band mode=8 (0x18052f306), а XML mode=1 — где маппинг.
|
||||||
|
|||||||
Reference in New Issue
Block a user