Я уже говорил, можно снимать биты (лучше просто 0x00), если оба бита установлены (маска 0xC0) при передаче. Тогда шум будет только когда кто-то реально используется CSM режим, а таких должно быть мало.
хотя еще не известно как это повлияет на звук соник танка.
А там тоже используется 7-й бит или 0xFF? Узнали как часто встречается реальное использование CSM режима, а не 0xFF, и сколько неправильных 0xFF (0xC0)? Хотя бы примерно, кроме Nightmare Circus.
Про тики, перемотку не понял. Вы наверно хотите полноценный редактор GEMS сделать. Если бы я делал графический плеер GEMS на основе этого (не редактор), то для промотки (seeking) загружал трек заново и в цикле пропускал нужное количество кадров:
for (int i = 0; i < frames_skip; i++) {
VBLINT();
gems_loop();
vgm_update();
for (loop = 0; loop < rateDACUpdate; loop++)
{
DACME();
}
PlayingTimer ++;
}
Это работает более менее быстро (не больше секунды для 2 минут перемотки), но возможно не точно из-за отсутствия ym2612_stream_update(), который заполняет буфер, с ним медленнее.
Для выяснения длины трека просто проматывал бы до конца, при этом пришлось бы учитывать зацикливание.
Кстати, заметил, что один и тот же короткий трек играл по-разному при разных запусках. Может там проблемы с потоком (с ними всегда проблемы, если не быть крайне осторожным и опытным), который отдельно играет музыку, или где-то используется неинициализированная память.
По-хорошему, для такого рода библиотеки должна быть возможность самому вызывать sound_update() с передачей буфера, тогда забота по воспроизведения ложится на пользователя библиотеки, зато можно лучше контролировать процесса.