As part of the loader work, we have also been reviewing how OutFox decides whether cached song data can still be used. Caching is essential for large libraries. Once a song has been parsed, the engine can save the result and avoid repeating the same work every time it starts.

That only helps when the saved data still matches the files on disk.

A chart may have been edited, a banner replaced, metadata corrected, or a parser changed since the cache entry was created. If the engine does not recognise that change, it can load stale information even though the source files are correct.

We have been tightening those checks across song data, edits and media so that OutFox can reuse cached results when they remain valid and rebuild them when they do not.

One fault uncovered during this work appeared as a difficulty meter of -2147483648.

That value came from an invalid conversion rather than anything written by the chart author. The obvious fix would have been to clamp unusual meter values globally, but that would also damage legitimate content with intentionally high ratings.

Instead, we corrected the specific conversion that produced the invalid integer while preserving the original floating-point meter data and authored values.

Threaded loading exposed another problem.

Some information that appeared local to one song load was actually being shared between several loads. Image fallback state and parts of the dynamic parser path could therefore produce different results depending on which thread reached them first.

We have kept the parts of threaded loading that are safe, while restoring ordered processing around the older code that still depends on shared state.

This is slower than declaring the whole loader parallel and hoping for the best, but it gives us consistent results between runs.

For players, the cache should simply do its job.

Unchanged songs should load more quickly. Edited charts and replaced media should be detected. Banners and previews should remain stable, and chart information should not change because the library happened to load in a different order.

The loader work is not only about making startup faster. It also has to make sure the faster result is the same result we would get from reading the source files again.