весь день проковырялся со сраной bass.dll библиотекой... и так и нет решения. если кто работал с энтой библиотекой и знает как реализовать эту задачу, о которой ниже - убедительная просьба отписаться
ну так вот - поскольку сэмплы в VGM файле были посчитаны моей системой как 15к и даже почти 20к частоты, чего быть не может - то задумка была брать и конвертить эти сэмплы из этих 15к в 10.4к для последующего использования в GEMS. и даже нашлась эта команда для изменения частоты в bass:
BASS_ChannelSetAttribute(tempostream, #BASS_ATTRIB_FREQ, frequencynew)но после этого если оригинальная частота была скажем 15, а стала 10 - то стало по сути меееедлееееннное проигрывание. а мне хотелось бы чтоб скорость проигрывания и высота оставалась нормальной, менялась просто частота дискретизации или как там она по научному... рыл рыл и вроде как рекомендуют увеличивать скорость проигрывания с помощью
BASS_ChannelSetAttribute(tempostream, #BASS_ATTRIB_TEMPO, proccount)однако я не вдупляю как теперь расчитать этот самый сраный коэфициент изменения proccount. я думал что примерно так:
proccount = (frequencyvalue - frequencynew) / (frequencyvalue / 100)
где frequencyvalue - оригинальное значение частоты, frequencynew - те заветные 10.4к
кароче фигня какая-то играет. заметно различаются сэмплы. а должно быть примерно одинаково. конечно с некоторой потерей качества, а оно так-же либо медленно либо быстро.
подумал может не тот параметр взял... там три было на выбор:
;BASS_ATTRIB_TEMPO The tempo of a channel in percent [-95%...0...+5000%].
;BASS_ATTRIB_TEMPO_PITCH The pitch of a channel in semitones [-60...0...+60].
;BASS_ATTRIB_TEMPO_FREQ The sample rate of a channel in Hz (but calculates by the same % As BASS_ATTRIB_TEMPO).
кароче весь день зазря потерял...
обиделся на это дело... и пошел рассинхрон с горя починил
добавив остаток деления к расчетной формуле. стало в этом плане гораздо лучше
итак текущие пока не решенные проблемы:
1. сраный bass.dll с фишкой пересохранения сэмплов под нужной частотой без изменения скорости проигрывания
2. сама система определения сэмплов готова лишь частично
3. громкость для инструментов не отслеживается4. одно из вкусностей - слайды
RRR треки должны быть обязательно конвертануты
из-за них можно сказать все и затевалось.
5. пока не дописывает в конце проигрывания самые последние ноты по дорожкам
6. система лупов не работает. если оригинальный VGM трек мог играть скажем 3 минуты, то конвертер будет конвертить только от начала и до конца самого файла, без учета loop. в результате трек как короче по длительности, так и гораздо больше по размеру из-за чрезмерного количества команд delay и pitch.
7. пока даже не в курсе как подступится ко второму музыкальному процессору. (например он воспроизводит перхоть - удары по тарелке в барабане. или в треках дюны например тихими такими звуками высокими добавляет атмосферности)
8. при встрече двух delay рядом происходит эпический тупняк мелодии. надо продумать этот момент.
9. не решаемая проблема - игра со стерео каналами в виду, по видимому, ограничения самого движка GEMS. если кто сможет поправить сам этот самый движок, чтобы инициализация проигрывания сэмплов там могла происходить с тремя вариантами:
FMWrite(2, 0xB6, 0xC0) (как оно сейчас. включает и левый и правый канал)
FMWrite(2, 0xB6, 0x40) (только правый)
FMWrite(2, 0xB6, 0x80) (только левый)
и чтоб это безобразие управлялось файлом инструмента sfx, где внизу была бы добавлена новая команда CHAN:
RAW 'sample_0B.snd'
FLAGS =$45
SKIP =$0000
FIRST =$0AA8
LOOP =$0000
END =$0000
CHAN =$0000$0000 - стерео, оба (на случай совместимости со старыми треками, где нет этого параметра в файле)
$0010 - правый (левый отключен этой единичкой) FMWrite(2, 0xB6, 0x40)
$0001 - левый (правый отключен этой единичкой) FMWrite(2, 0xB6, 0x80)
если сам движок может еще и получится поправить, то вот комбайн-программу мы хер переделаем
шелл где-то блудит и явно переделывать это дело не будет.
