-
Notifications
You must be signed in to change notification settings - Fork 215
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
YM2610 ADPCM-A/B sample padding is incorrect #1910
Comments
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. |
issue #1910 may or may not fix the issue. testing needed.
A fix has been pushed. I will test later but if you want to help, feel free to test. |
Better but still not 100% correct: padding should be either 0x80 or 0x08 depending on last encoded sample, and that can't be told before running the encoder. Correct fix is to insert 0 value samples at the end of source data until reaching a 512 boundary, yma_encode/ymb_encode will therefor produce a 256 bytes boundary sample with the correct padding. Sorry I'm not familiar with the codebase, not sure where to resize source data for a clean fix. |
Sadly, that's difficult. Sorry. The problem is when the sample in the song is in ADPCM-A or ADPCM-B format (this is the case for Neo Volley) - we don't know how to end the sample. |
Another easy way you can fix this is edit yma_encode/ymb_encode, so it continues encoding 0 values when len isn't 512 multiple.
(or make a separate yma_encode_padded function if that suits you better) Issue with arbitrary 0x80 fill is it will hold the last sample value instead of falling back to 0, with the extremely rare odd case of over/underflow depending on what the last value was. |
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: