Producers upload whole tracks, not 60s clips. Before, a large file was either
413-rejected at the edge or buffered wholesale in RAM (upload read + content
hash + engine decode each copied the whole file). Now ingest, hashing and the
signal/loudness engines all stream in bounded windows, so peak memory is
O(window) not O(file) and a big upload can't OOM the shared box.
- engines/streaming.py: probe() + windows() — bounded window iterator over the
whole file at native SR (soundfile streams WAV/FLAC/OGG/MP3, exact frames).
- onsets/waveform/spectrum: full-track. waveform/spectrum aggregate EXACTLY
(fixed output grid filled by a streaming reduction); onsets concatenates
per-window onset envelopes (tiny) for near-exact global tempo/hits.
- loudness: full-track; peak/true-peak/RMS/crest exact, integrated LUFS
energy-weighted across windows (pyloudnorm gating can't merge chunks exactly)
and flagged approximate:true / lufs_method:chunked.
- clip-tier (emotion/features/samples/analyze/grade/naming) stay head-analysis
(a 5-min track's 'sample role' is meaningless) but every response now carries
an honest source{duration_s,sr,channels,size_bytes} block.
- app ingest streams the upload to disk (never one big read); size ceiling read
per-request. content_id streams the decode-to-hash, byte-identical to the old
whole-file hash so the deployed cache stays warm. Upload cap 40->100MB to
match the gateway.
- tests: test_fulltrack.py proves >60s coverage, content_id stability, exact
streaming reductions, contiguous windowing. Full suite green (parity w/ base).
