Amourman/inzynierka-transformer-100k

inzynierka-transformer-100k

100 000 presetów syntezatora, stokenizowane pod trening Transformer-VAE. Rekordy leżą na gładkich i spójnych brzmieniowo trajektoriach w przestrzeni brzmienia, cel modelu to przestrzeń latentna, po której da się organicznie ewoluować brzmienie z seeda w duchu Synplant2 od Sonic Charge.

Każdy fragment kodu który jest w tym README jest od codexa, żeby nakierować na poprawne uzycie tego repo, bo jest zagmatwane troche

tl;dr

• —100 000 rekordów: Splity są przygotowane: train 80 108 / validation 10 103 / test 9 789 — nieregularne liczby, bo całe trajektorie trafiają po jednej stronie podziału.
• —`preset_tokens/`: Preset jako 14 tokenów modułów
• —`audio_tokens/`: Kody z EnCodeca.
• —`features/` i `manifest.jsonl` nie wchodzą jako input do modelu, to katalog metryk na temat datasetu do późniejszej analizy i metadane rekordów w JSONie, możesz sobie zerknąć.
• —Wiersz [i] w każdym preset_tokens/*.npy i features/*.npy odpowiada linii [i] w manifest.jsonl. Audio szukasz po (record_id, view_id) w audio_tokens/audio_token_index.jsonl. Wszystko spinane jest kluczem record_id.
• —EnCodec:, 8 codebooks × 1024 symbols, 75 kl/s. Tokenizowany jest tylko główny sampel midi_60: 450 klatek = 6 s (bo generalnie renderowane były 3 sample per preset, ale tylko do liczenia metryk generacji na różnych czestotliwościach). Model i tak używa wyłącznie 'midi_60'. 100 000 wierszy tokenów audio.

drzewo repo

manifest.jsonl                  katalog: 1 rekord / linia, metadane
preset_tokens/                  Input treningu: preset jako tensory, 14 tokenów modułów
audio_tokens/                   Input treninu: kody EnCodec w shardach + indeks
features/                       Cechy do budowy zbioru
audit_report.json               17-testowa bramka jakości (wszystkie zdane, to od Codexa)
generation_summary.json         pełna konfiguracja przebiegu generacji (też kontrolnie od Codexa)
render_attempts.jsonl           każda próba renderu, w tym odrzucone ~98k (chyba warto zatrzymać)
sound_archive_calibration.json  geometria datasetu skalowanie + PCA + CVT (CVT to Centra Teselacji Woronoja, do wyboru centr nisz dźwiękowych przy ewolucj)
vae_analysis_report.json        analiza zbioru pod trening (od codexa)
viewer/                         tylko po to zeby HF dobrze robil poglad datasetu

pliki po kolei

manifest.jsonl

1 obiekt JSON na linię, 100 000 linii. Najważniejsze pola:

import json
recs = [json.loads(l) for l in open("manifest.jsonl", encoding="utf-8")]

preset_tokens/

Preset jako 14 tokenów modułów: OSC A/B, FM, mikser źródeł, filtr, obwiednie, LFO, FX itp. Każdy z ≤7 parametrami i ≤5 trasami modulacji. Pliki statyczne opisują strukturę, per-rekordowe niosą wartości.

import numpy as np
pv  = np.load("preset_tokens/parameter_values.npy", mmap_mode="r")  # (100000,14,7)
mod = np.load("preset_tokens/module_activity.npy",  mmap_mode="r")  # (100000,14)
i = 42
preset_i = pv[i]           # tensor presetu rekordu i (= linia i w manifest.jsonl)

audio_tokens/

Dźwięk skompresowany EnCodekiem 24 kHz do kodów: 8 codebooków × 450 klatek, wartości 0–1023. Tokenizowany jest midi_60. Preset renderowany jest na 3 częstotliwosciach 48/60/72 do walidacji DSP w generacji datasetu, ale jako tokeny zapisane jest wyłącznie midi_60.

• —shardy audio_tokens-XXXXX.npz 391 plików, po ≤256 widoków, każdy ma:
• —codes - (rows, 8, 450) uint16 - kody
• —lengths - (rows,) int32 - długość dla midi_60 zawsze 450
• —indeks audio_token_index.jsonl 100 000 linii: dla każdego record_id podaje shard, row, token_length, split.
• —codec_metadata.json — konfiguracja kodeka (to od codexa).

100 000 widoków × 8 × 450 to ~2 GB. Jeden plik trzeba by ładować w całości; podział na shardy po 256 pozwala dopisywać w trakcie generacji i wznawiać strumieniowanie: dataloader będzie mógł wczytać tylko potrzebny shard i bierze z niego jeden wiersz bez trzymania całosci datasetu w RAM.

Nie ciągniesz shardów ręcznie, tylko przez indeks:

import json, numpy as np
idx = {}                                   # (record_id, view) -> (shard, row, len)
for l in open("audio_tokens/audio_token_index.jsonl", encoding="utf-8"):
    e = json.loads(l); idx[(e["record_id"], e["view_id"])] = (e["shard"], e["row"], e["token_length"])

shard, row, T = idx[("qd-7-branch-2-00012345:5:0", "midi_60")]
codes = np.load(f"audio_tokens/{shard}")["codes"][row][:, :T]   # (8, T) uint16, wartości 0..1023

features/

• —local_features.npy (100000, 3555) float32: lokalne cechy percepcji (multi-res log-mel), do liczenia słyszalnej odległości między krokami trajektori.
• —global_features.npy (100000, 696) float32: to dla 3 wavów, wiec na jeden przypada (100000, 232) | co to | rozmiar | co to jest faktycznie | |---|---|---| | statystyki mel | 192 | 3 rozmiary FFT (512, 2048, 8192) × 2 (średnia + odchylenie std po czasie) × 32 pasma mel = 3·2·32 | | obwiednia RMS | 32 | głośność w 32 binach czasu — kształt narastania i gaśnięcia dźwięku | | deskryptory widmowe | 8 | rmsdB, spectralcentroid (jasność), spectralbandwidth (szerokość), spectralrolloff, spectralflatness (szum↔ton), zerocrossingrate, temporalcentroid (gdzie „środek ciężkości" energii w czasie), crest_factor (szczyt/RMS) |

jak złożyć jeden przykład treningowy

# rekord i:  i = linia w manifest.jsonl = wiersz w preset_tokens/*.npy = wiersz w features/*.npy
rec   = recs[i]
enc_preset = {                              # WEJŚCIE/CEL: preset
    "parameter_values":  pv[i],             # (14,7) float32
    "parameter_activity": pa[i],            # (14,7) bool
    "module_activity":   mod[i],            # (14,)  bool
    # + statyczne: module_ids, module_activity_mask, parameter_mask, route_mask
}
codes  = load_view(rec["record_id"], "midi_60")   # (8, T) — WEJŚCIE/CEL: audio
split  = rec["split"]                              # train / validation / test
weight = rec["activity_mask"]                      # do ważenia straty na parametrach

Enkoder dostaje preset + kody audio midi_60 -> rzutuje do 32-wymiarowego latentu -> dekoder odtwarza z powrotem kody audio, 37 parametrów, aktywność i routing.

trajektorie

record_id = trajektoria:krok:próba. Rekordy jednej trajektorii mają wspólny trajectory_id i rosnący step_index sąsiednie kroki różnią się małą wartością metryki 'log-mel-FFT'. prev / current / next maja ten sam trajectory_id. Kolejne step_index to wartości na potencjalną lossfunction pilnującą spójnego kierunku w przestrzeni latentnej.

split train-test-val jak są podzielone

Podział grupuje po liniach seedów rootseedid: cała trajektoria trafia w train lub validation lub test. Weź używaj pola split` i nie tasuj tego jeszcze raz bo byś rozdzielił trajektorie.