You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is an issue with the way samples are padded to fit the 256 bytes boundaries restriction.
Currently, samples are encoded and stored in ROM data, the data is then padded with 0x00 to the next 0x100 boundary. This produces incorrect data at the end of the sample, albeit for a very small time period:
Samples should be extended to the correct size prior to encoding to produce correct padding up to the next boundary in ROM data.
The text was updated successfully, but these errors were encountered:
I need to add this is from the Neo Seaside NG sample track coming with Furnace, pictured data is ADPCM-B data block from VGM export (after assigning each sample to the correct region, as track puts them in both A & B by default; So basically B region only has that one sample).
Also that sample actually ends @0x1a5ff, so reported issue is still valid but only in range 0x1a5fb - 0x1a5ff unlike pictured.
However this shows us data banks have extra 256bytes of unused blank data added at their end. (0x1a600-0x1a6ff here, found that extra block in A and B regions)
So this is the actual issue, sorry for the confusion:
There is an issue with the way samples are padded to fit the 256 bytes boundaries restriction.
Currently, samples are encoded and stored in ROM data, the data is then padded with 0x00 to the next 0x100 boundary. This produces incorrect data at the end of the sample, albeit for a very small time period:
Samples should be extended to the correct size prior to encoding to produce correct padding up to the next boundary in ROM data.
The text was updated successfully, but these errors were encountered: