template<typename T, size_t ChunkSize = 4096>
class audio_tools::ChunkedSampleTableStore< T, ChunkSize >
RAM-backed like RamSampleTableStore, but grows by allocating additional fixed-size chunks instead of reallocating and copying one single growing array.
This project's Vector<T>::push_back() (AudioBasic/Collections/Vector.h) allocates exactly the new size on every growth, with no spare capacity
- once the array is full, every single push_back() reallocates and copies everything already in it. For the hundreds of thousands of entries a feature-length movie's stsz/stco tables need, that's O(N) work per append, O(N^2) total, which is real, measured wall-clock time spent before a single frame can play.
This store sidesteps that by keeping a Vector of chunk pointers rather than a Vector of T directly: growing by one chunk means appending one more pointer (cheap - the pointer vector itself stays tiny, e.g. ~70 pointers for 288K entries at the default chunk size) and allocating a fresh fixed-size block, without ever touching or copying any previously-appended data. Same total memory as RamSampleTableStore, but O(1) amortized append instead of O(N) - the same idea behind this project's DynamicMultiBuffer (AudioTools/Sandbox/DynamicMultiBuffer.h), reimplemented directly here rather than wrapped: that class's public API is a sequential read()/write() cursor, not the indexed get() ChunkedSampleTableStore needs, and as Sandbox-status code it's not something to take a hard dependency on from a container decoder.