It is possible for a song to accidentally include a duplicate sample. It turns out that the duplicate sample is not being optimized properly into a matching SRCN ID, at least in SPC compilation, which leads to memory consumption. The example case that I have, provided by Ahrion (it had already been fixed on the SMWCentral side song submission-wise) resulted in a memory overflow as a result.
I had done some modifications through #121 and #123 previously. I suspected that #124 may have accidentally broken some kind of duplicate check that was being done in the optimization process...
After further analysis, I have determined that this is caused by the important sample marker and will also require a SNES-side intervention to avoid loading duplicate samples. Previously they would be turned into EMPTY.brr samples, but now this is not the case. For me personally, I'm leaning towards copying the pointers outright in order to avoid mayhem with regards to inconsistent SRCN IDs. Plus, this can be replicated on 1.0.8 through the sample groups themselves by duplicating an important marker sample there, meaning the filtering on 1.0.8 only succeeded in handling the duplicate IDs, and not the double loading problem.
Reported by Ahrion.
It is possible for a song to accidentally include a duplicate sample. It turns out that the duplicate sample is not being optimized properly into a matching SRCN ID, at least in SPC compilation, which leads to memory consumption. The example case that I have, provided by Ahrion (it had already been fixed on the SMWCentral side song submission-wise) resulted in a memory overflow as a result.
I had done some modifications through #121 and #123 previously. I suspected that #124 may have accidentally broken some kind of duplicate check that was being done in the optimization process...
After further analysis, I have determined that this is caused by the important sample marker and will also require a SNES-side intervention to avoid loading duplicate samples. Previously they would be turned into EMPTY.brr samples, but now this is not the case. For me personally, I'm leaning towards copying the pointers outright in order to avoid mayhem with regards to inconsistent SRCN IDs. Plus, this can be replicated on 1.0.8 through the sample groups themselves by duplicating an important marker sample there, meaning the filtering on 1.0.8 only succeeded in handling the duplicate IDs, and not the double loading problem.