Building the RBXL Stats tool (upload a .rbxl/.rbxm, get an instant object count without opening Studio) went smoothly right up until I tested it on a real place file instead of a small model export. It failed with a cryptic error buried in a third-party parsing library: [ByteReader.LZ4] invalid match offset.

Chasing the wrong theory first

My first assumption was an off-by-one in how the chunk headers were being read. I wrote a byte-level dump of the file and manually walked the header fields, name, compressed length, uncompressed length, reserved bytes, and they all checked out. So the header parsing wasn't the problem.

The actual clue

I cross-checked the raw compressed bytes against a second, independent LZ4 decoder, and it failed differently, not the same way, which ruled out a simple boundary bug and pointed at something more fundamental: the bytes themselves weren't LZ4 at all.

A quick hex dump of the chunk's first four bytes confirmed it: 28 B5 2F FD, the magic number for Zstandard, not LZ4. Roblox has apparently moved newer binary format chunks to Zstd compression, and the parsing library I was using had no idea, it was feeding Zstd bytes into an LZ4 decoder and getting garbage.

The fix

Node has built-in Zstd support in zlib as of a recent version, so the fix didn't need a new dependency, just a small runtime patch that detects the Zstd magic number and routes to zlib.zstdDecompressSync instead of the library's own (correct, for actual LZ4 data) decoder. Tested against a real place file afterward: 4,385 instances parsed cleanly.